System and method for enhanced virtual queuing with access control for secured systems

ABSTRACT

A system and method for managing virtual queues for providing access control. A cloud-based queue service manages a plurality of queues hosted by one or more entities. The queue service is in constant communication with the entities and sensors located therein providing queue management, queue analysis, and access control to controlled systems. The queue service is likewise in direct communication with queued persons and provides an access key to a user device which can be used to access the controlled system when certain conditions are met.

CROSS-REFERENCE TO RELATED APPLICATIONS

Priority is claimed in the application data sheet to the followingpatents or patent applications, each of which is expressly incorporatedherein by reference in its entirety:

-   17/667,910-   17/667,855-   17/667,034-   17/235,408-   16/836,798-   16/542,577-   62/820,190-   17/389,837-   16/985,093-   16/583,967-   62/828,133-   16/523,501-   15/411,424

BACKGROUND OF THE INVENTION Field of the Art

The disclosure relates to queuing, specifically to the field ofcloud-implemented automated virtual queuing systems.

Discussion of the State of the Art

Queues have been around for at least 185 years. With urbanization andpopulation growth increasing the length of most queues by orders ofmagnitude in some situations. The design of the queue has changedever-so-slightly, zig-zagging the line for example, but the basic queueremains relatively unchanged. That was up until virtual queuing camearound in the form of paper tickets and more recently electronic pagers.However, these new modes require a queued person to remain withinearshot of an announcement or within visual range of a monitor, in thecase of paper tickets. In the case of pagers, a queued person is stilllimited in physical space by the range of the pager. Newer virtualqueuing systems have been devised to use a person’s mobile device, butstill haven’t really added much to queuing. These current solutions failto efficiently facilitate or even address at all the complexity ofmultiple queues, punctuality concerns and no-shows, and simply does nottake advantage of modern-day advantages such as “Big Data.”

What is needed is a system and method for virtual queuing that overcomesthe limitations of the prior art as noted above by organizing andmotivating multiple persons between multiple queues and taking fulladvantage of the breadth of data available to make predictions andorganize queues while providing access control to secure systems andprocesses.

SUMMARY OF THE INVENTION

Accordingly, the inventor has conceived and reduced to practice, asystem and method for managing virtual queues for providing accesscontrol. A cloud-based queue service manages a plurality of queueshosted by one or more entities. The queue service is in constantcommunication with the entities and sensors located therein providingqueue management, queue analysis, and access control to controlledsystems. The queue service is likewise in direct communication withqueued persons and provides an access key to a user device which can beused to access the controlled system when certain conditions are met.

According to a first preferred embodiment, a system for enhanced virtualqueuing with access control, comprising: a computing device comprising amemory, a processor, and a nonvolatile data storage device; a queuemanager comprising a first plurality of programming instructions storedin the memory which, when operating on the processor, causes theprocessor to: receive a user request to join a virtual queue for acontrolled system; assign the user a queue position; continuouslymonitor the queue state by analyzing data received from a plurality ofsensors; and notify the user when the user has reached the front of thequeue; and a security module comprising a second plurality ofprogramming instructions stored in the memory which, when operating onthe processor, causes the processor to: generate an access key for theuser; send the access key to a user device associated with the user; andprovide access to the controlled system when the user has reached thefront of the queue by detecting the access key using one of theplurality of sensors.

According to a second preferred embodiment, a method for enhancedvirtual queuing with access control, comprising the steps of: receivinga user request to join a virtual queue for a controlled system;assigning the user a queue position; continuously monitoring the queuestate by analyzing data received from a plurality of sensors; notifyingthe user when the user has reached the front of the queue; generating anaccess key for the user; sending the access key to a user deviceassociated with the user; and providing access to the controlled systemwhen the user has reached the front of the queue by detecting the accesskey using one of the plurality of sensors.

According to an aspect of an embodiment, the queue manager is furtherconfigured to detect a queue event based on the analysis of the receiveddata from the plurality of sensors and send detected event data to aqueue load balancer.

According to an aspect of an embodiment, the queue load balancercomprising a third plurality of programming instructions stored in thememory which, when operating on the processor, causes the processor to:receive the detected event data from the queue manager; calculate acurrent queue throughput based on the received event data; compare thecurrent queue throughput to a predicted throughput to determine anestimated wait time; and reassign the user among a plurality of virtualqueues to minimize the wait time.

According to an aspect of an embodiment, the controlled system is aphysical system.

According to an aspect of an embodiment, the controlled system is avirtual system.

According to an aspect of an embodiment, the queue event is selectedfrom the group consisting of a request to join the virtual queue, arequest to leave the virtual queue, and additional queues opening orclosing.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The accompanying drawings illustrate several aspects and, together withthe description, serve to explain the principles of the inventionaccording to the aspects. It will be appreciated by one skilled in theart that the particular arrangements illustrated in the drawings aremerely exemplary, and are not to be considered as limiting of the scopeof the invention or the claims herein in any way.

FIG. 1 is a block diagram illustrating an exemplary system architecturefor operating a callback cloud, according to one aspect.

FIG. 2 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating over a public switched telephone networkand internet, to a variety of other brand devices and services,according to an embodiment.

FIG. 3 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating including a calendar server, over apublic switched telephone network and internet, to a variety of otherbrand devices and services, according to an embodiment.

FIG. 4 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating including a brand interface server, overa public switched telephone network and internet, to a variety of otherbrand devices and services, according to an embodiment.

FIG. 5 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating including a brand interface server andintent analyzer, over a public switched telephone network and internet,to a variety of other brand devices and services, according to anembodiment.

FIG. 6 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating including a privacy server, over a publicswitched telephone network and internet, to a variety of other branddevices and services, according to an embodiment.

FIG. 7 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating including a bot server, over a publicswitched telephone network and internet, to a variety of other branddevices and services, according to an embodiment.

FIG. 8 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating including an operations analyzer over apublic switched telephone network and internet, to a variety of otherbrand devices and services, according to an embodiment.

FIG. 9 is a block diagram illustrating an exemplary system architecturefor a callback cloud including a brand interface server, an intentanalyzer, and a broker server, operating over a public switchedtelephone network and internet, to a variety of other brand devices andservices, according to an embodiment.

FIG. 10 is a diagram illustrating trust circles of levels of privacy fora user of a callback cloud, according to an aspect.

FIG. 11 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, according to an embodiment.

FIG. 12 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a calendar server,according to an embodiment.

FIG. 13 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including gathering ofenvironmental context data of users, according to an embodiment.

FIG. 14 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a brand interfaceserver and intent analyzer, according to an embodiment.

FIG. 15 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a privacy server,according to an embodiment.

FIG. 16 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a bot server,according to an embodiment.

FIG. 17 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including an operationsanalyzer, according to an embodiment.

FIG. 18 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a brand interfaceserver, intent analyzer, and broker server, according to an embodiment.

FIG. 19 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, according to an embodiment.

FIG. 20 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a calendar server, according to anembodiment.

FIG. 21 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a brand interface server, according to anembodiment.

FIG. 22 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a brand interface server and intentanalyzer, according to an embodiment.

FIG. 23 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a privacy server, according to anembodiment.

FIG. 24 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a bot server, according to an embodiment.

FIG. 25 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including an operations analyzer, according to anembodiment.

FIG. 26 is a block diagram illustrating an exemplary hardwarearchitecture of a computing device.

FIG. 27 is a block diagram illustrating an exemplary logicalarchitecture for a client device.

FIG. 28 is a block diagram showing an exemplary architecturalarrangement of clients, servers, and external services.

FIG. 29 is another block diagram illustrating an exemplary hardwarearchitecture of a computing device.

FIG. 30 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a brand interface server, intentanalyzer, and broker server, according to an embodiment.

FIG. 31 is a block diagram illustrating an exemplary system for acloud-based virtual queuing platform, according to an embodiment.

FIG. 32 is a block diagram illustrating an exemplary system architectureand the possible communication means for a cloud-based virtual queuingplatform, according to an embodiment.

FIG. 33 is a block diagram illustrating an exemplary system architecturefor a queue service, according to an embodiment.

FIG. 34 is a block diagram showing an exemplary use of a cloud-basedqueue service, according to one aspect.

FIG. 35 is a method diagram illustrating the use of a cloud-basedvirtual queuing platform with an end-device, according to an embodiment.

FIG. 36 is a method diagram illustrating another use of a cloud-basedvirtual queuing platform with an end-device, according to an embodiment.

FIG. 37 is a block diagram illustrating signage used to initiatebi-directional communication between a cloud-based virtual queuingplatform and an end-device, according to one aspect.

FIG. 38 is a block diagram illustrating one aspect of an exemplarymobile application used in bi-directional communication between acloud-based virtual queuing platform and an end-device, according to oneaspect.

FIG. 39 is a block diagram illustrating another aspect of an exemplarymobile application used in bi-directional communication between acloud-based virtual queuing platform and an end-device, according to oneaspect.

FIG. 40 is a block diagram illustrating a graph output from an analysismodule, according to one aspect.

FIG. 41 is a block diagram illustrating another graph output from ananalysis module, according to one aspect.

FIG. 42 is a flow diagram illustrating a web-based GPS aspect of acloud-based virtual queuing platform, according to an embodiment.

FIG. 43 is a flow diagram illustrating another web-based GPS aspect of acloud-based virtual queuing platform, according to an embodiment.

FIG. 44 is a table diagram showing an exemplary and simplifiedrules-based notification escalation plan, according to one aspect.

FIG. 45 is a table diagram showing an exemplary and simplifiedrules-based notification escalation plan that further uses locationdata, according to one aspect.

FIG. 46 is a message flow diagram illustrating the exchange of messagesand data between components of a cloud-based virtual queuing platformfor sequential event queue management, according to an embodiment.

FIG. 47 is a flow diagram illustrating a load-balancing aspect of acloud-based virtual queuing platform, according to an embodiment.

FIG. 48 is a method diagram illustrating a one-time password aspect in acloud-based virtual queuing platform, according to an embodiment.

FIG. 49 is a block diagram illustrating an exemplary system architecturefor a queue manager with task blending and accumulation, according to anembodiment.

FIG. 50 is a block diagram illustrating a graph representing taskblending opportunities based on queue throughput, according to oneaspect.

FIG. 51 is a block diagram illustrating four exemplary queue models usedfor queue simulations, according to one aspect.

FIG. 52 is a method diagram illustrating task blending in a cloud-basedvirtual queuing platform, according to an embodiment.

FIG. 53 is a method diagram illustrating an accumulation service used ina cloud-based virtual queuing platform, according to an embodiment.

FIG. 54 is a block diagram illustrating an exemplary system architecturefor a machine learning prediction module based on queue theory andpsychology, according to an embodiment.

FIG. 55 is a flow diagram illustrating an exemplary queue configurationmethod used in a cloud-based virtual queuing platform, according to anembodiment.

FIG. 56 is a flow diagram illustrating an exemplary wait-time predictionmethod used in a cloud-based virtual queuing platform, according to anembodiment.

FIG. 57 is a block diagram illustrating an exemplary system forproviding enhanced queue management with access control, according to anembodiment.

FIG. 58 is a message flow diagram illustrating an exemplary exchange ofdata messages between and among various components of a system forenhanced virtual queue management with access control.

FIG. 59 is a flow diagram illustrating an exemplary process formonitoring a virtual queue and reassigning queue positions baseddetected events, according to an embodiment.

FIG. 60 is a flow diagram illustrating an exemplary method for managinga virtual queue for a controlled system, according to an embodiment.

DETAILED DESCRIPTION OF THE DRAWING FIGURES

The inventor has conceived, and reduced to practice, a system and methodfor managing virtual queues. A cloud-based queue service manages aplurality of queues hosted by one or more entities. The queue service isin constant communication with the entities providing queue management,queue analysis, and queue recommendations. The queue service is likewisein direct communication with queued persons. Sending periodic updateswhile also motivating and incentivizing punctuality and minimizing waittimes based on predictive analysis. The predictive analysis uses “BigData” and other available data resources, for which the predictionsassist in the balancing of persons across multiple queues for the sameevent or multiple persons across a sequence of lines for sequentialevents.

One or more different aspects may be described in the presentapplication. Further, for one or more of the aspects described herein,numerous alternative arrangements may be described; it should beappreciated that these are presented for illustrative purposes only andare not limiting of the aspects contained herein or the claims presentedherein in any way. One or more of the arrangements may be widelyapplicable to numerous aspects, as may be readily apparent from thedisclosure. In general, arrangements are described in sufficient detailto enable those skilled in the art to practice one or more of theaspects, and it should be appreciated that other arrangements may beutilized and that structural, logical, software, electrical and otherchanges may be made without departing from the scope of the particularaspects. Particular features of one or more of the aspects describedherein may be described with reference to one or more particular aspectsor figures that form a part of the present disclosure, and in which areshown, by way of illustration, specific arrangements of one or more ofthe aspects. It should be appreciated, however, that such features arenot limited to usage in the one or more particular aspects or figureswith reference to which they are described. The present disclosure isneither a literal description of all arrangements of one or more of theaspects nor a listing of features of one or more of the aspects thatmust be present in all arrangements.

Headings of sections provided in this patent application and the titleof this patent application are for convenience only, and are not to betaken as limiting the disclosure in any way.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or morecommunication means or intermediaries, logical or physical.

A description of an aspect with several components in communication witheach other does not imply that all such components are required. To thecontrary, a variety of optional components may be described toillustrate a wide variety of possible aspects and in order to more fullyillustrate one or more aspects. Similarly, although process steps,method steps, algorithms or the like may be described in a sequentialorder, such processes, methods and algorithms may generally beconfigured to work in alternate orders, unless specifically stated tothe contrary. In other words, any sequence or order of steps that may bedescribed in this patent application does not, in and of itself,indicate a requirement that the steps be performed in that order. Thesteps of described processes may be performed in any order practical.Further, some steps may be performed simultaneously despite beingdescribed or implied as occurring non-simultaneously (e.g., because onestep is described after the other step). Moreover, the illustration of aprocess by its depiction in a drawing does not imply that theillustrated process is exclusive of other variations and modificationsthereto, does not imply that the illustrated process or any of its stepsare necessary to one or more of the aspects, and does not imply that theillustrated process is preferred. Also, steps are generally describedonce per aspect, but this does not mean they must occur once, or thatthey may only occur once each time a process, method, or algorithm iscarried out or executed. Some steps may be omitted in some aspects orsome occurrences, or some steps may be executed more than once in agiven aspect or occurrence.

When a single device or article is described herein, it will be readilyapparent that more than one device or article may be used in place of asingle device or article. Similarly, where more than one device orarticle is described herein, it will be readily apparent that a singledevice or article may be used in place of the more than one device orarticle.

The functionality or the features of a device may be alternativelyembodied by one or more other devices that are not explicitly describedas having such functionality or features. Thus, other aspects need notinclude the device itself.

Techniques and mechanisms described or referenced herein will sometimesbe described in singular form for clarity. However, it should beappreciated that particular aspects may include multiple iterations of atechnique or multiple instantiations of a mechanism unless notedotherwise. Process descriptions or blocks in figures should beunderstood as representing modules, segments, or portions of code whichinclude one or more executable instructions for implementing specificlogical functions or steps in the process. Alternate implementations areincluded within the scope of various aspects in which, for example,functions may be executed out of order from that shown or discussed,including substantially concurrently or in reverse order, depending onthe functionality involved, as would be understood by those havingordinary skill in the art.

Definitions

“Callback” as used herein refers to an instance of an individual beingcontacted after their initial contact was unsuccessful. For instance, ifa first user calls a second user on a telephone, but the second userdoes not receive their call for one of numerous reasons includingturning off their phone or simply not picking up, the second user maythen place a callback to the first user once they realize they missedtheir call. This callback concept applies equally to many forms ofinteraction that need not be restricted to telephone calls, for exampleincluding (but not limited to) voice calls over a telephone line, videocalls over a network connection, or live text-based chat such as webchat or short message service (SMS) texting, email, and other messagingapplications (e.g., WhatsApp, etc.). While a callback (and variousassociated components, methods, and operations taught herein) may alsobe used with an email communication despite the inherently asynchronousnature of email (participants may read and reply to emails at any time,and need not be interacting at the same time or while other participantsare online or available), the preferred usage as taught herein refers tosynchronous communication (that is, communication where participants areinteracting at the same time, as with a phone call or chatconversation).

“Callback object” as used herein means a data object representingcallback data, such as the identities and call information for a firstand second user, the parameters for a callback including what time itshall be performed, and any other relevant data for a callback to becompleted based on the data held by the callback object.

“Latency period” as used herein refers to the period of time betweenwhen a Callback Object is created and the desired Callback is initiated,for example, if a callback object is created and scheduled for a timefive hours from the creation of the object, and the callback initiateson-time in five hours, the latency period is equal to the five hoursbetween the callback object creation and the callback initiation.

“Brand” as used herein means a possible third-party service or devicethat may hold a specific identity, such as a specific MAC address, IPaddress, a username or secret key which can be sent to a cloud callbacksystem for identification, or other manner of identifiable device orservice that may connect with the system. Connected systems or servicesmay include a Private Branch Exchange (“PBX”), call router, chat serverwhich may include text or voice chat data, a Customer RelationshipManagement (“CRM”) server, an Automatic Call Distributor (“ACD”), or aSession Initiation Protocol (“SIP”) server.

Conceptual Architecture

FIG. 1 is a block diagram of a preferred embodiment of the invention,illustrating an exemplary architecture of a system 100 for providing acallback cloud service. According to the embodiment, callback cloud 101may receive requests 140 via a plurality of communications networks suchas a public switched telephone network (PSTN) 103 or the Internet 102.These requests may comprise a variety of communication and interactiontypes, for example including (but not limited to) voice calls over atelephone line, video calls over a network connection, or livetext-based chat such as web chat or short message service (SMS) textingvia PSTN 103.

Such communications networks may be connected to a plurality of consumerendpoints 110 and enterprise endpoints 120 as illustrated, according tothe particular architecture of communication network involved. Exemplaryconsumer endpoints 110 may include, but are not limited to, traditionaltelephones 111, cellular telephones 112, mobile tablet computing devices113, laptop computers 114, or desktop personal computers (PC) 115. Suchdevices may be connected to respective communications networks via avariety of means, which may include telephone dialers, VOIPtelecommunications services, web browser applications, SMS textmessaging services, or other telephony or data communications services.It will be appreciated by one having ordinary skill in the art that suchmeans of communication are exemplary, and many alternative means arepossible and becoming possible in the art, any of which may be utilizedas an element of system 100 according to the invention.

A PSTN 103 or the Internet 102 (and it should be noted that not allalternate connections are shown for the sake of simplicity, for examplea desktop PC 126 may communicate via the Internet 102) may be furtherconnected to a plurality of enterprise endpoints 120, which may comprisecellular telephones 121, telephony switch 122, desktop environment 125,internal Local Area Network (LAN) or Wide-Area Network (WAN) 130, andmobile devices such as tablet computing device 128. As illustrated,desktop environment 125 may include both a telephone 127 and a desktopcomputer 126, which may be used as a network bridge to connect atelephony switch 122 to an internal LAN or WAN 130, such that additionalmobile devices such as tablet PC 128 may utilize switch 122 tocommunicate with PSTN 102. Telephone 127 may be connected to switch 122or it may be connected directly to PSTN 102. It will be appreciated thatthe illustrated arrangement is exemplary, and a variety of arrangementsthat may comprise additional devices known in the art are possible,according to the invention.

Callback cloud 101 may respond to requests 140 received fromcommunications networks with callbacks appropriate to the technologyutilized by such networks, such as data or Voice over Internet Protocol(VOIP) callbacks 145, 147 sent to Internet 102, or time-divisionmultiplexing (TDM) such as is commonly used in cellular telephonynetworks such as the Global System for Mobile Communications (GSM)cellular network commonly used worldwide, or VOIP callbacks to PSTN 103.Data callbacks 147 may be performed over a variety of Internet-enabledcommunications technologies, such as via e-mail messages, applicationpop-ups, or Internet Relay Chat (IRC) conversations, and it will beappreciated by one having ordinary skill in the art that a wide varietyof such communications technologies are available and may be utilizedaccording to the invention. VOIP callbacks may be made using either, orboth, traditional telephony networks such as PSTN 103 or over VOIPnetworks such as Internet 102, due to the flexibility to the technologyinvolved and the design of such networks. It will be appreciated thatsuch callback methods are exemplary, and that callbacks may be tailoredto available communications technologies according to the invention.

Additionally, callback cloud 101 may receive estimated wait time (EWT)information from an enterprise 120 such as a contact center. Thisinformation may be used to estimate the wait time for a caller beforereaching an agent (or other destination, such as an automated billingsystem), and determine whether to offer a callback proactively beforethe customer has waited for long. EWT information may also be used toselect options for a callback being offered, for example to determineavailability windows where a customer’s callback is most likely to befulfilled (based on anticipated agent availability at that time), or tooffer the customer a callback from another department or location thatmay have different availability. This enables more detailed and relevantcallback offerings by incorporating live performance data from anenterprise, and improves customer satisfaction by saving additional timewith preselected recommendations and proactively-offered callbacks.

FIG. 2 is a block diagram illustrating an exemplary system architecturefor a callback cloud operating over a public switched telephone networkand the Internet, and connecting to a variety of other brand devices andservices, according to an embodiment. A collection of user brands 210may be present either singly or in some combination, possibly includinga Public Branch Exchange (“PBX”) 211, a Session Initiation Protocol(“SIP”) server 212, a Customer Relationship Management (“CRM”) server213, a call router 214, or a chat server 215, or some combination ofthese brands. These brands 210 may communicate over a combination of, oronly one of, a Public Switched Telephone Network (“PSTN”) 103, and theInternet 102, to communicate with other devices including a callbackcloud 220, a company phone 121, or a personal cellular phone 112. A SIPserver 212 is responsible for initiating, maintaining, and terminatingsessions of voice, video, and text or other messaging protocols,services, and applications, including handling of PBX 211 phonesessions, CRM server 213 user sessions, and calls forwarded via a callrouter 214, all of which may be used by a business to facilitate diversecommunications requests from a user or users, reachable by phone 121,112 over either PSTN 103 or the Internet 102. A chat server 215 may beresponsible for maintaining one or both of text messaging with a user,and automated voice systems involving technologies such as an AutomatedCall Distributor (“ACD”), forwarding relevant data to a call router 214and CRM server 213 for further processing, and a SIP server 212 forgenerating communications sessions not run over the PSTN 103. Varioussystems may also be used to monitor their respective interactions (forexample, chat session by a chat server 215 or phone calls by an ACD orSIP server 212), to track agent and resource availability for producingEWT estimations.

When a user calls from a mobile device 112 or uses some communicationapplication such as (for example, including but not limited to) SKYPE™or instant messaging, which may also be available on a laptop or othernetwork endpoint other than a cellular phone 112, they may be forwardedto brands 210 operated by a business in the manner described herein. Forexample, a cellular phone call my be placed over PSTN 103 before beinghandled by a call router 214 and generating a session with a SIP server212, the SIP server creating a session with a callback cloud 220 with aprofile manager 221 if the call cannot be completed, resulting in acallback being required. A profile manager 221 manages the storage,retrieval, and updating of user profiles, including global and localuser profiles. The profile manager 221, which may be located in acallback cloud 220 receives initial requests to connect to callbackcloud 220, and forwards relevant user profile information to a callbackmanager 223, which may further request environmental context data froman environment analyzer 222. Environmental context data may include (forexample, and not limited to) recorded information about when a callbackrequester or callback recipient may be suspected to be driving orcommuting from work, for example, and may be parsed from online profilesor online textual data, using an environment analyzer 222.

A callback manager 223 centrally manages all callback data, creating acallback programming object which may be used to manage the data for aparticular callback, and communicates with an interaction manager 224which handles requests to make calls and bridge calls, which go out to amedia server 225 which actually makes the calls as requested. Forexample, interaction manager 224 may receive a call from a callbackrequester, retrieve callback parameters for that callback requester fromthe callback manager 223, and cause the media server 225 to make a callto a callback recipient while the callback requester is still on theline, thus connecting the two parties. After the call is connected, thecallback programming object used to make the connection may be deleted.The interaction manager 224 may subsequently provide changed callbackparameters to the callback manager 223 for use or storage. In this way,the media server 225 may be altered in the manner in which it makes andbridges calls when directed, but the callback manager 223 does not needto adjust itself, due to going through an intermediary component, theinteraction manager 224, as an interface between the two. A media server225, when directed, may place calls and send messages, emails, orconnect voice over IP (“VoIP”) calls and video calls, to users over aPSTN 103 or the Internet 102. Callback manager 223 may work with auser’s profile as managed by a profile manager 221, with environmentalcontext from an environment analyzer 222 as well as (if provided) EWTinformation for any callback recipients (for example, contact centeragents with the appropriate skills to address the callback requestor’sneeds, or online tech support agents to respond to chat requests), todetermine an appropriate callback time for the two users (a callbackrequestor and a callback recipient), interfacing with an interactionmanager 224 to physically place and bridge the calls with a media server225. In this way, a user may communicate with another user on a PBXsystem 211, or with automated services hosted on a chat server 215, andif they do not successfully place their call or need to be called backby a system, a callback cloud 220 may find an optimal time to bridge acall between the callback requestor and callback recipient, asnecessary.

FIG. 3 is a block diagram illustrating an exemplary system architecturefor a callback cloud including a calendar server operating over a publicswitched telephone network and the Internet, and connected to a varietyof other brand devices and services, according to an embodiment.According to this embodiment, many user brands 310 are present,including PBX system 311, a SIP server 312, a CRM server 313, a callrouter 314, and a chat server 315, which may be connected variously toeach other as shown, and connected to a PSTN 103 and the Internet 102,which further connect to a cellular phone 112 and a landline 121 orother phone that may not have internet access. As further shown,callback cloud 320 contains multiple components, including a calendarserver 321, profile manager 322, environment analyzer 323, callbackmanager 324, interaction manager 325, and media server 326, whichsimilarly to user brands 310 may be interconnected in various ways asdepicted in the diagram, and connected to either a PSTN 103 or theinternet 102.

A calendar server 321, according to the embodiment, is a server whichmay store and retrieve, either locally or from internet-enabled servicesassociated with a user, calendars which hold data on what times a usermay be available or busy (or some other status that may indicate otherspecial conditions, such as to allow only calls from certain sources)for a callback to take place. A calendar server 321 connects to theinternet 102, and to a profile manager 322, to determine the times acallback requestor and callback recipient may both be available.

FIG. 4 is a block diagram illustrating an exemplary system architecturefor a callback cloud including a brand interface server, operating overa public switched telephone network and the Internet, and connected to avariety of other brand devices and services, according to an embodiment.According to this embodiment, many user brands 410 are present,including PBX system 411, a SIP server 412, a CRM server 413, a callrouter 414, and a chat server 415, which may be connected variously toeach other as shown, and connected to a PSTN 103 and the Internet 102,which further connect to a cellular phone 112 and a landline 121 orother phone that may not have internet access. As further shown,callback cloud 420 contains multiple components, including a profilemanager 421, environment analyzer 422, callback manager 423, interactionmanager 424, and media server 425, which similarly to user brands 410may be interconnected in various ways as depicted in the diagram, andconnected to either a PSTN 103 or the internet 102.

Present in this embodiment is a brand interface server 430, which mayexpose the identity of, and any relevant API’s or functionality for, anyof a plurality of connected brands 410, to elements in a callback cloud420. In this way, elements of a callback cloud 420 may be able toconnect to, and interact more directly with, systems and applicationsoperating in a business’ infrastructure such as a SIP server 412, whichmay be interfaced with a profile manager 421 to determine the exactnature of a user’s profiles, sessions, and interactions in the systemfor added precision regarding their possible availability and mostimportantly, their identity.

FIG. 5 is a block diagram illustrating an exemplary system architecturefor a callback cloud including a brand interface server and intentanalyzer, operating over a public switched telephone network and theInternet, and connected to a variety of other brand devices andservices, according to an embodiment. According to this embodiment, manyuser brands 510 are present, including PBX system 511, a SIP server 512,a CRM server 513, a call router 514, and a chat server 515, which may beconnected variously to each other as shown, and connected to a PSTN 103and the Internet 102, which further connect to a cellular phone 112 anda landline 121 or other phone that may not have internet access. Furthershown is a callback cloud 520 contains multiple components, including aprofile manager 521, environment analyzer 522, callback manager 523,interaction manager 524, and media server 525, which similarly to userbrands 510 may be interconnected in various ways as depicted in thediagram, and connected to either a PSTN 103 or the internet 102.

Present in this embodiment is a brand interface server 530, which mayexpose the identity of, and any relevant API’s or functionality for, anyof a plurality of connected brands 510, to elements in a callback cloud520. In this way, elements of a callback cloud 520 may be able toconnect to, and interact more directly with, systems and applicationsoperating in a business’ infrastructure such as a SIP server 512, whichmay be interfaced with a profile manager 521 to determine the exactnature of a user’s profiles, sessions, and interactions in the systemfor added precision regarding their possible availability and mostimportantly, their identity. Also present in this embodiment is anintent analyzer 540, which analyzes spoken words or typed messages froma user that initiated the callback request, to determine their intentfor a callback. For example, their intent may be to have an hour-longmeeting, which may factor into the decision by a callback cloud 520 toplace a call shortly before one or both users may be required to startcommuting to or from their workplace. Intent analysis may utilize anycombination of text analytics, speech-to-text transcription, audioanalysis, facial recognition, expression analysis, posture analysis, orother analysis techniques, and the particular technique or combinationof techniques may vary according to such factors as the device type orinteraction type (for example, speech-to-text may be used for avoice-only call, while face/expression/posture analysis may beappropriate for a video call), or according to preconfigured settings(that may be global, enterprise-specific, user-specific,device-specific, or any other defined scope).

FIG. 6 is a block diagram illustrating an exemplary system architecturefor a callback cloud including a privacy server, operating over a publicswitched telephone network and the Internet, and connected to a varietyof other brand devices and services, according to an embodiment.According to this embodiment, many user brands 610 are present,including PBX system 611, a SIP server 612, a CRM server 613, a callrouter 614, and a chat server 615, which may be connected variously toeach other as shown, and connected to a PSTN 103 and the Internet 102,which further connect to a cellular phone 112 and a landline 121 orother phone that may not have internet access. As further shown, acallback cloud 620 contains multiple components, including a profilemanager 622, environment analyzer 623, callback manager 624, interactionmanager 625, and media server 626, which similarly to user brands 610may be interconnected in various ways as depicted in the diagram, andconnected to either a PSTN 103 or the internet 102.

In this embodiment, a privacy server 621 may connect to the internet102, and to a profile manager 622 as well as a callback manager 624, andallows for callback requestors to first be validated using trust-circlesto determine if they are a trusted user. A trusted user may be definedusing a variety of criteria (that may vary according to the user,interaction, device, enterprise, or other context), and may for examplecomprise a determination of whether the callback requestor is a friendor family member, or is using a trusted brand such as a piece ofequipment from the same company that the callback recipient works at, orif the callback requestor is untrusted or is contacting unknownrecipients, to determine if a callback request is permitted based onuser settings. Further, a privacy server 621 may encrypt one or both ofincoming and outgoing data from a callback manager 624 in such a way asto ensure that, for example, a callback recipient might not know whorequested the callback, or their profile may not be visible to therecipient, or vice versa, and other privacy options may also be enabledas needed by a corporation.

Encryption may utilize public or private keys, or may utilize perfectforward secrecy (such that even the enterprise routing the call cannotdecrypt it), or other encryption schema or combinations thereof that mayprovide varying features or degrees of privacy, security, or anonymity(for example, one enterprise may permit anonymous callbacks whileanother may require a user to identify themselves and may optionallyverify this identification).

FIG. 7 is a block diagram illustrating an exemplary system architecturefor a callback cloud including a bot server, operating over a publicswitched telephone network and the Internet, and connected to a varietyof other brand devices and services, according to an embodiment.According to this embodiment, many user brands 710 are present,including PBX system 711, a SIP server 712, a CRM server 713, a callrouter 714, and a chat server 715, which may be connected variously toeach other as shown, and connected to a PSTN 103 and the Internet 102,which further connect to a cellular phone 112 and a landline 121 orother phone that may not have internet access. As further shown, acallback cloud 720 contains multiple components, including a profilemanager 721, environment analyzer 722, callback manager 723, interactionmanager 725, and media server 726, which similarly to user brands 710may be interconnected in various ways as depicted in the diagram, andconnected to either a PSTN 103 or the internet 102.

In the present embodiment, a bot server 724 also is present in acallback cloud 720, which allows for communication with a callbackrequestor. Bot server 724 allows a user to specify, through anyavailable data type such as (including, but not limited to) SMS texting,email, or audio data, any desired parameters for the callback they wouldlike to request. This is similar to an ACD system used by individualcall-centers, but exists as a separate server 724 in a cloud service 720which may then be configured as-needed by a hosting company, and behavesakin to an automated secretary, taking user information down to specifya callback at a later time from the callback recipient.

FIG. 8 is a block diagram illustrating an exemplary system architecturefor a callback cloud including an operations analyzer operating over apublic switched telephone network and the Internet, and connected to avariety of other brand devices and services, according to an embodiment.According to this embodiment, many user brands 810 are present,including PBX system 811, a SIP server 812, a CRM server 813, a callrouter 814, and a chat server 815, which may be connected variously toeach other as shown, and connected to a PSTN 103 and the Internet 102,which further connect to a cellular phone 112 and a landline 121 orother phone that may not have internet access. As further shown, acallback cloud 820 contains multiple components, including a profilemanager 821, environment analyzer 822, callback manager 823, interactionmanager 825, and media server 826, which similarly to user brands 810may be interconnected in various ways as depicted in the diagram, andconnected to either a PSTN 103 or the internet 102.

In this embodiment, an operations analyzer 824 is present, which maydetermine a particular channel to be used to reach a callback recipientand callback requestor, for example (and not limited to), VoIP servicessuch as SKYPE™ or DISCORD™, a PSTN phone connection, any particularphone number or user accounts to connect using, or other service, todetermine the optimal method with which to reach a user during acallback. An operations analyzer 824 may also analyze and determine thepoints of failure in a callback cloud 820, if necessary, for example ifa callback attempt fails to connect operations analyzer 824 may bridge acallback requestor and recipient using an alternate communicationchannel to complete the callback at the scheduled time.

FIG. 9 is a block diagram illustrating an exemplary system architecturefor a callback cloud including a brand interface server, an intentanalyzer, and a broker server, operating over a public switchedtelephone network and internet, and connected to a variety of otherbrand devices and services, according to an embodiment. According tothis embodiment, many user brands 910 are present, including PBX system911, a SIP server 912, a CRM server 913, a call router 914, and a chatserver 915, which may be connected variously to each other as shown, andconnected to a PSTN 103 and the Internet 102, which further connect to acellular phone 112 and a landline 121 or other phone that may not haveinternet access. As further shown, a callback cloud 920 containsmultiple components, including a profile manager 921, environmentanalyzer 922, callback manager 923, interaction manager 924, and mediaserver 925, which similarly to user brands 910 may be interconnected invarious ways as depicted in the diagram, and connected to either a PSTN103 or the internet 102. Also present are a plurality of networkendpoints 960, 970, connected to either or both of the internet 102 anda PSTN 103, such network endpoints representing contact points otherthan a landline 121 or cell phone 112, including laptops, desktops,tablet computers, or other communication devices.

Present in this embodiment is a brand interface server 930, which mayexpose the identity of, and any relevant API’s or functionality for, anyof a plurality of connected brands 910, to an intent analyzer 940. Inthis way, elements of a callback cloud 920 may be able to connect to,and interact more directly with, systems and applications operating in abusiness’ infrastructure such as a SIP server 912, which may beinterfaced with a profile manager 921 to determine the exact nature of auser’s profiles, sessions, and interactions in the system for addedprecision regarding their possible availability and most importantly,their identity. An intent analyzer 940 may analyze spoken words or typedmessages from a user that initiated the callback request, to determinetheir intent for a callback, as well as forward data received from abrand interface server. For example, their intent may be to have anhour-long meeting, which may factor into the decision by a callbackcloud 920 to place a call shortly before one or both users may berequired to start commuting to or from their workplace. An intentanalyzer 940 may forward all data through a broker server 950 which mayallocate specific actions and responses to take between third-partybrands 910 and callback cloud 920 components, as needed, as well asforward all data from the exposed and interfaced elements with thecallback cloud 920.

FIG. 10 is a diagram illustrating trust circles of levels of privacy fora user of a callback cloud, according to an aspect. These trust circlesare data constructs enforced by a privacy server 621 which aredetermined with a profile manager 622, which indicate the level of trustthat callers may possess, and therefore the system’s ability to schedulea callback with the caller and the recipient. A caller who calls from arecognized brand 1010, for example a company’s phone forwarded throughtheir PBX 611, may be recognized as having the highest level of trust,due to coming from a recognized source within the same organization.Family 1020 may (for example) be the second highest level of trust,allowing for just as many privileges with callbacks, or perhapsrestricting callback requests to only certain hours, to prevent usersfrom being disrupted during certain work hours. A callback recipient’sfriends 1030 may occupy a level of trust lower than that of family,representing users less-trusted than family 1020 callers, and may yethave more restricted access to making callback requests for a user, anda continuing, descending hierarchy may be used to model additionallevels of trust. For example, additional trust levels may include (butare not limited to) social media 1040 recognized users, colleagues 1050which may represent individuals only loosely affiliated with a potentialcallback recipient, and untrusted 1060, representing users who are knownto the system and deemed banned or untrustworthy, having the lowestability to request an automated callback connection with a user. Afurther level of trust may exist, outside of the trust-circle paradigm,representing unknown contacts 1070, which, depending on the settings foran individual user or an organization using a callback cloud system 620,may be unable to request callbacks, or may only be able to requestcallbacks at certain restricted hours until they are set to a higherlevel of trust in the system, according to a preferred embodiment.

As shown in FIG. 10 , trust circles need not be implicitly hierarchicalin nature and may overlap in various ways similar to a logical Venndiagram. For example one individual may be a friend and also known onsocial media, or someone may be both family and a colleague (as iscommonplace in family businesses or large companies that may employ manypeople). As shown, anybody may be considered “untrusted” regardless oftheir other trust groupings, for example if a user does not wish toreceive callbacks from a specific friend or coworker. While thearrangement shown is one example, it should be appreciated that a widevariety of numerous overlapping configuration may be possible witharbitrary complexity, as any one person may be logically placed withinany number of groups as long as the trust groupings themselves are notexclusive (such as a group for coworkers and one for individuals outsidethe company).

Expanding on the notion of trust circles, there may also be logical“ability” circles that correspond to various individuals’ capabilitiesand appropriateness for various issues, such as (for example) techsupport skill or training with specific products, or whether a member ofa brand 1010 is actually a member of the best brand to handle a specificreason for a callback, based on the callback request context. Forexample, a customer requesting a callback for assistance with booking aflight may not be adequately served by employees of airlines that don’toffer flights to their intended destination, so combining the brandtrust zone 1010 with a capability map would indicate to the callbacksystem which individuals are more appropriate for the callback inquestion. This expands from merely trusting certain users and discardingothers, to a form of automated virtual concierge service that finds theuser for a callback request that is most capable and relevant to therequest, ensuring optimum handling of the callback requestor’s needs.

FIG. 11 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, according to an embodiment.According to an embodiment, a callback cloud 220 must receive a requestfor a callback to a callback recipient, from a callback requester 1110.This refers to an individual calling a user of a cloud callback system220, being unable to connect for any reason, and the system allowing thecaller to request a callback, thus becoming the callback requester, fromthe callback recipient, the person they were initially unable to reach.A callback object is instantiated 1120, using a callback manager 223,which is an object with data fields representing the various parts ofcallback data for a callback requester and callback recipient, and anyrelated information such as what scheduled times may be possible forsuch a callback to take place. Global profiles may then be retrieved1130 using a profile manager 221 in a cloud callback system, as well asan analysis of environmental context data 1140, allowing for the systemto determine times when a callback may be possible for a callbackrequestor and callback recipient both 1150. When such a time arrives, afirst callback is attempted 1160 to the callback requestor or callbackrecipient, and if this succeeds, a second call is attempted to thesecond of the callback requestor and callback recipient 1170, allowing amedia server 225 to bridge the connection when both are online, beforedeleting the callback object 1180.

FIG. 12 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a calendar server,according to an embodiment. According to an embodiment, a callback cloud320 must receive a request for a callback to a callback recipient, froma callback requester 1205. This refers to an individual calling a userof a cloud callback system 320, being unable to connect for any reason,and the system allowing the caller to request a callback, thus becomingthe callback requester, from the callback recipient, the person theywere initially unable to reach. A callback object is instantiated 1210,using a callback manager 324, which is an object with data fieldsrepresenting the various parts of callback data for a callback requesterand callback recipient, and any related information such as whatscheduled times may be possible for such a callback to take place.Global profiles may then be retrieved 1215 using a profile manager 322which manages the storage and retrieval of user profiles, includingglobal and local user profiles. The profile manager 322, which may belocated in a cloud callback system, interfaces with user-specificcalendars 1220 to find dates and timeslots on their specific calendarsthat they both may be available 1225 through use of a calendar server321, as well as an analysis of environmental context data 1230, allowingfor the system to determine times when a callback may be possible for acallback requestor and callback recipient both 1235. When such a timearrives, a first callback is attempted 1240 to the callback requestor orcallback recipient, and if this succeeds, a second call is attempted tothe second of the callback requestor and callback recipient 1245,allowing a media server 326 to bridge the connection when both areonline, before deleting the callback object 1250.

FIG. 13 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including gathering ofenvironmental context data of users, according to an embodiment.According to an embodiment, a callback cloud 420 may interface with abrand interface server 430, which may interface with third-party orproprietary brands of communications devices and interfaces such asautomated call distributor systems 1305. Through this brand interface,the system may receive a request for a callback to a callback recipient,from a callback requester 1310. This refers to an individual calling auser of a cloud callback system 420, being unable to connect for anyreason, and the system allowing the caller to request a callback, thusbecoming the callback requester, from the callback recipient, the personthey were initially unable to reach. A callback object is instantiated1315, using a callback manager 423, which is an object with data fieldsrepresenting the various parts of callback data for a callback requesterand callback recipient, and any related information such as whatscheduled times may be possible for such a callback to take place.Global profiles may then be retrieved 1320 using a profile manager 421in a cloud callback system, as well as an analysis of environmentalcontext data 1325, allowing for the system to determine times when acallback may be possible for a callback requestor and callback recipientboth 1330. When such a time arrives, a first callback is attempted 1335to the callback requestor or callback recipient, and if this succeeds, asecond call is attempted to the second of the callback requestor andcallback recipient 1340, allowing a media server 425 to bridge theconnection when both are online, before deleting the callback object1345.

FIG. 14 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a brand interfaceserver and intent analyzer, according to an embodiment. According to anembodiment, a callback cloud 520 may interface with a brand interfaceserver 530, which may interface with third-party or proprietary brandsof communications devices and interfaces such as automated calldistributor systems 1405. Through this brand interface, the system mayreceive a request for a callback to a callback recipient, analyzingtheir intent from the provided input 1410, followed by processing it asa callback request 1415. Callback requestor intent in this case mayindicate how long or what times are preferred for a callback to takeplace, which may be taken into account for a callback 1410. This refersto an individual calling a user of a cloud callback system 520, beingunable to connect for any reason, and the system allowing the caller torequest a callback, thus becoming the callback requester, from thecallback recipient, the person they were initially unable to reach. Acallback object is instantiated 1420, using a callback manager 523,which is an object with data fields representing the various parts ofcallback data for a callback requester and callback recipient, and anyrelated information such as what scheduled times may be possible forsuch a callback to take place. Global profiles may then be retrieved1425 using a profile manager 521 in a cloud callback system, as well asan analysis of environmental context data 1430, allowing for the systemto determine times when a callback may be possible for a callbackrequestor and callback recipient both 1435. When such a time arrives, afirst callback is attempted 1440 to the callback requestor or callbackrecipient, and if this succeeds, a second call is attempted to thesecond of the callback requestor and callback recipient 1445, allowing amedia server 525 to bridge the connection when both are online, beforedeleting the callback object 1450.

FIG. 15 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a privacy server,according to an embodiment. According to an embodiment, a callback cloud620 must receive a request for a callback to a callback recipient, froma callback requester 1505. This refers to an individual calling a userof a cloud callback system 620, being unable to connect for any reason,and the system allowing the caller to request a callback, thus becomingthe callback requester, from the callback recipient, the person theywere initially unable to reach. When a callback request is received1505, trust-circle rules are enforced using a privacy server 621, 1510preventing untrusted users from requesting a callback, or insufficientlytrusted users from scheduling callbacks at specific times or perhapspreventing them from requesting callbacks with certain callbackrecipients, depending on the privacy settings of a given callbackrecipient. All data may also be encrypted 1515 for added security, usinga privacy server 621. If a callback request is allowed to proceed, acallback object is instantiated 1520, using a callback manager 624,which is an object with data fields representing the various parts ofcallback data for a callback requester and callback recipient, and anyrelated information such as what scheduled times may be possible forsuch a callback to take place. Global profiles may then be retrieved1525 using a profile manager 622 in a cloud callback system, as well asan analysis of environmental context data 1530, allowing for the systemto determine times when a callback may be possible for a callbackrequestor and callback recipient both 1535. When such a time arrives, afirst callback is attempted 1540 to the callback requestor or callbackrecipient, and if this succeeds, a second call is attempted to thesecond of the callback requestor and callback recipient 1545, allowing amedia server 626 to bridge the connection when both are online, beforedeleting the callback object 1550.

FIG. 16 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a bot server,according to an embodiment. According to an embodiment, a callback cloud720 may first utilize a bot server 724 to receive an automated callbackrequest from a user 1605, which may allow a user to specify theirparameters for a callback directly to the system. The system may thenreceive a request for a callback to a callback recipient, from acallback requester 1610. This refers to an individual calling a user ofa cloud callback system 720, being unable to connect for any reason, andthe system allowing the caller to request a callback, thus becoming thecallback requester, from the callback recipient, the person they wereinitially unable to reach. A callback object is instantiated 1615, usinga callback manager 723, which is an object with data fields representingthe various parts of callback data for a callback requester and callbackrecipient, and any related information such as what scheduled times maybe possible for such a callback to take place. Global profiles may thenbe retrieved 1620 using a profile manager 721 in a cloud callbacksystem, as well as an analysis of environmental context data 1625,allowing for the system to determine times when a callback may bepossible for a callback requestor and callback recipient both 1630. Whensuch a time arrives, a first callback is attempted 1635 to the callbackrequestor or callback recipient, and if this succeeds, a second call isattempted to the second of the callback requestor and callback recipient1640, allowing a media server 726 to bridge the connection when both areonline, before deleting the callback object 1645.

FIG. 17 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including an operationsanalyzer, according to an embodiment. According to an embodiment, acallback cloud 820 must receive a request for a callback to a callbackrecipient, from a callback requester 1705. This refers to an individualcalling a user of a cloud callback system 820, being unable to connectfor any reason, and the system allowing the caller to request acallback, thus becoming the callback requester, from the callbackrecipient, the person they were initially unable to reach. A callbackobject is instantiated 1710, using a callback manager 823, which is anobject with data fields representing the various parts of callback datafor a callback requester and callback recipient, and any relatedinformation such as what scheduled times may be possible for such acallback to take place. Global profiles may then be retrieved 1715 usinga profile manager 821 in a cloud callback system, as well as an analysisof environmental context data 1720, allowing for the system to determinetimes when a callback may be possible for a callback requestor andcallback recipient both 1725. When such a time arrives, a first callbackis attempted 1730 to the callback requestor or callback recipient, andif this succeeds, a second call is attempted to the second of thecallback requestor and callback recipient 1735, allowing a media server826 to bridge the connection when both are online, before deleting thecallback object 1740. An operations analyzer 824 may then monitoroperation of components and communication channels involved in thecallback, analyze the results of the attempted callback bridge, and ifit was unsuccessful, determine whether a component or communicationchannel of a callback cloud experiences a failure, and either select analternate communication channel to complete the callback at a scheduledtime or store such results 1745 for viewing by a later systemadministrator.

FIG. 18 is a method diagram illustrating the use of a callback cloud forintent-based active callback management, including a brand interfaceserver, intent analyzer, and broker server, according to an embodiment.According to an embodiment, a callback cloud 920 may interface with abrand interface server 930, which may interface with third-party orproprietary brands of communications devices and interfaces such asautomated call distributor systems 1805. Through this brand interface,the system may receive a request for a callback to a callback recipient,analyzing their intent from the provided input 1810, before a brokerserver 940 communicates this request to the callback cloud 920, 1820 andnot only exposes but also manages connections and interactions betweenvarious brands 910 and a callback cloud 920, 1815. The system may thenprocess a callback request 1820. Callback requestor intent in this casemay indicate how long or what times are preferred for a callback to takeplace, which may be taken into account for a callback 1810. This refersto an individual calling a user of a cloud callback system 920, beingunable to connect for any reason, and the system allowing the caller torequest a callback, thus becoming the callback requester, from thecallback recipient, the person they were initially unable to reach.After receiving at least one callback request, a broker server 940 mayfurther manage dealings between multiple callback requests and more thantwo requestors or recipients 1825, selecting a plurality of specificactions to take during a callback and allocating each selected action toa system component involved in the callback. The broker server 940 mayorganize successive or nested callback attempts by user availability andtimes available, as well as the times the requests are received 1830. Atleast one callback object is then instantiated 1835, using a callbackmanager 923, which is an object with data fields representing thevarious parts of callback data for a callback requester and callbackrecipient, and any related information such as what scheduled times maybe possible for such a callback to take place. Global profiles may thenbe retrieved 1840 using a profile manager 921 in a cloud callbacksystem, as well as an analysis of environmental context data 1845,allowing for the system to determine times when a callback may bepossible for a callback requestor and callback recipient both 1850. Whensuch a time arrives, a first callback is attempted 1855 to the callbackrequestor or callback recipient, and if this succeeds, a second call isattempted to the second of the callback requestor and callback recipient1860, allowing a media server 925 to bridge the connection when both areonline, before deleting the callback object 1865.

FIG. 19 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, according to an embodiment. Key componentsexchanging messages in this embodiment include a callback manager 1905,a profile manager 1910, an environment analyzer 1915, an interactionmanager 1920, and a media server 1925. A callback request is made 1930,which is forwarded to a callback manager 1915. A callback manager thenrequests profile information on a callback requestor and recipient 1935,a profile manager 1910 then requesting environmental context 1940 froman environment analyzer 1915. Profile information and environmentalcontext information are both sent to the callback manager 1945, beforean interaction manager is sent the time for an attempted callback 1950,which then, at the designated time, sends the relevant IP addresses,usernames, phone numbers, or other pertinent connection information to amedia server 1955. The call results are sent back to an interactionmanager 1960, which then sends the finished result of the attempt atbridging the callback to the callback manager 1965.

FIG. 20 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a calendar server, according to anembodiment. Key components exchanging messages in this embodimentinclude a callback manager 2005, a profile manager 2010, an environmentanalyzer 2015, an interaction manager 2020, a media server 2025, and acalendar server 2030. A callback request is made 2035, which isforwarded to a callback manager 2015. A callback manager then requestsprofile information on a callback requestor and recipient 2040, aprofile manager 2010 then requesting environmental context 2045 from anenvironment analyzer 2015. Profile information and environmental contextinformation are both sent to the callback manager 2050, before a profilemanager may request calendar schedules 2055 from both a callbackrequestor and a callback recipient, using a calendar server 2030. Ifcalendars are available for either or both users, they are forwarded tothe callback manager 2060. The interaction manager is then sent the timefor an attempted callback 2065, which then, at the designated time,sends the relevant IP addresses, usernames, phone numbers, or otherpertinent connection information to a media server 2070. The callresults are sent back to an interaction manager 2075, which then sendsthe finished result of the attempt at bridging the callback to thecallback manager 2080.

FIG. 21 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a brand interface server, according to anembodiment. Key components exchanging messages in this embodimentinclude a callback manager 2105, a profile manager 2110, an environmentanalyzer 2115, an interaction manager 2120, a media server 2125, and abrand interface server 2130. A callback request is made 2135, which isforwarded to a callback manager 2115. A brand interface server mayidentify the devices or services communicating with the callback cloudsystem 2140, and possibly allow for communication back to such servicesand devices. A callback manager then requests profile information on acallback requestor and recipient 2145, a profile manager 2110 thenrequesting environmental context 2150 from an environment analyzer 2115.Profile information and environmental context information are both sentto the callback manager 2155, before an interaction manager is sent thetime for an attempted callback 2160, which then, at the designated time,sends the relevant IP addresses, usernames, phone numbers, or otherpertinent connection information to a media server 2165. The callresults are sent back to an interaction manager 2170, which then sendsthe finished result of the attempt at bridging the callback to thecallback manager 2175.

FIG. 22 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a brand interface server and intentanalyzer, according to an embodiment. Key components exchanging messagesin this embodiment include a callback manager 2205, a profile manager2210, an environment analyzer 2215, an interaction manager 2220, a mediaserver 2225, a brand interface server 2230, and an intent analyzer 2235.After a callback request is made, a brand interface server may forwardraw data from the services or applications used in making the request toan intent analyzer 2240, before identifying the devices or servicescommunicating with the callback cloud system 2245 and sending such datato a callback manager. An intent analyzer may then send data on callbackrequest intent 2250 to a callback manager 2205, which may indicate suchthings as the time a user may want to receive a callback, or what daysthey may be available, or how long the callback may take, which mayaffect the availability of timeslots for both a callback requestor andrecipient. A callback manager then requests profile information on acallback requestor and recipient 2255, a profile manager 2210 thenrequesting environmental context 2260 from an environment analyzer 2215.Profile information and environmental context information are both sentto the callback manager 2265, before an interaction manager is sent thetime for an attempted callback 2270, which then, at the designated time,sends the relevant IP addresses, usernames, phone numbers, or otherpertinent connection information to a media server 2275. The callresults are sent back to an interaction manager 2280, which then sendsthe finished result of the attempt at bridging the callback to thecallback manager 2285.

FIG. 23 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a privacy server, according to anembodiment. Key components exchanging messages in this embodimentinclude a callback manager 2305, a profile manager 2310, an environmentanalyzer 2315, an interaction manager 2320, a media server 2325, and aprivacy server 2330. A callback request is made 2335, which is forwardedto a callback manager 2315. A callback manager may then request privacysettings 2340 from a privacy server 2330, being forwarded the privacysettings 2345 from said server, including information on a user’s trustcircles as needed. A callback manager 2305 then requests profileinformation on a callback requestor and recipient 2350, a profilemanager 2310 then requesting environmental context 2355 from anenvironment analyzer 2315. Profile information and environmental contextinformation are both sent to the callback manager 2360, before aninteraction manager is sent the time for an attempted callback 2365,which then, at the designated time, sends the relevant IP addresses,usernames, phone numbers, or other pertinent connection information to amedia server 2370. The call results are sent back to an interactionmanager 2375, which then sends the finished result of the attempt atbridging the callback to the callback manager 2380.

FIG. 24 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a bot server, according to an embodiment.Key components exchanging messages in this embodiment include a callbackmanager 2405, a profile manager 2410, an environment analyzer 2415, aninteraction manager 2420, a media server 2425, and a bot server 2430. Acallback request is made 2435, which is forwarded to a bot server 2430.A bot server may handle a user in a similar manner to an automated calldistribution server for example, allowing a user to communicate verballyor textually with it, or it may instead handle results from a chatserver and parse the results of a user interacting with another chatserver 715. A callback manager may then receive parsed callback data2440 from a bot server 2430. A callback manager 2405 then requestsprofile information on a callback requestor and recipient 2445, aprofile manager 2410 then requesting environmental context 2450 from anenvironment analyzer 2415. Profile information and environmental contextinformation are both sent to the callback manager 2455, before aninteraction manager is sent the time for an attempted callback 2460,which then, at the designated time, sends the relevant IP addresses,usernames, phone numbers, or other pertinent connection information to amedia server 2465. The call results are sent back to an interactionmanager 2470, which then sends the finished result of the attempt atbridging the callback to the callback manager 2475.

FIG. 25 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including an operations analyzer, according to anembodiment. Key components exchanging messages in this embodimentinclude a callback manager 2505, a profile manager 2510, an environmentanalyzer 2515, an interaction manager 2520, a media server 2525, and anoperations analyzer 2530. A callback request is made 2535, which isforwarded to a callback manager 2505. A callback manager then requestsprofile information on a callback requestor and recipient 2540, aprofile manager 2510 then requesting environmental context 2545 from anenvironment analyzer 2515. Profile information and environmental contextinformation are both sent to the callback manager 2550, allowing acallback manager to forward initial callback object data to anoperations analyzer 2555, before an interaction manager is sent the timefor an attempted callback 2560, which then, at the designated time,sends the relevant IP addresses, usernames, phone numbers, or otherpertinent connection information to a media server 2565. The callresults are sent back to an interaction manager 2570, which then sendsthe finished result of the attempt at bridging the callback to thecallback manager 2575. At the end of this sequence, the callback resultdata, including any failures or lack of ability to bridge a call for acompleted callback between at least two users, is forwarded to anoperations analyzer 2580 for possible review by a human, if needed, andfor adjustment of the parameters the system uses in attempts to makecallbacks for said users.

FIG. 30 is a message flow diagram illustrating the exchange of messagesand data between components of a callback cloud for intent-based activecallback management, including a brand interface server, intentanalyzer, and broker server, according to an embodiment. Key componentsexchanging messages in this embodiment include a callback manager 3005,a profile manager 3010, an environment analyzer 3015, an interactionmanager 3020, a media server 3025, a brand interface server 3030, anintent analyzer 3035, and a broker server 3090. After a callback requestis made, a brand interface server may forward raw data 3040 from theservices or applications used in making the request to an intentanalyzer 3035, before identifying the devices or services communicatingwith the callback cloud system and sending such data to a broker server3090, which identifies and exposes brand information 3045 to thecallback cloud while managing connections between the callback cloud andvarious brands. An intent analyzer may then send data on callbackrequest intent 3050 to broker server 3090, which forwards thisinformation to a callback manager 3005, which may indicate such thingsas the time a user may want to receive a callback, or what days they maybe available, or how long the callback may take, which may affect theavailability of timeslots for both a callback requestor and recipient. Acallback manager then requests profile information on a callbackrequestor and recipient 3055, a profile manager 3010 then requestingenvironmental context 3060 from an environment analyzer 3015. Profileinformation and environmental context information are both sent to thecallback manager 3065, before an interaction manager is sent the timefor an attempted callback 3070, which then, at the designated time,sends the relevant IP addresses, usernames, phone numbers, or otherpertinent connection information to a media server 3075. The callresults are sent back to an interaction manager 3080, which then sendsthe finished result of the attempt at bridging the callback to thecallback manager 3085.

FIG. 31 is a block diagram illustrating an exemplary system for acloud-based virtual queuing platform 3100, according to an embodiment. Acloud-based virtual queuing platform 3100 establishes and managesvirtual queues associated with real or virtual events hosted by entities3102 and attended by end-devices or persons with end-devices 3101. Thebenefits of cloud-based queue management comprise cost savings,security, flexibility, mobility, insight offerings, increasedcollaboration, enhanced quality control, redundant disaster recovery,loss prevention, automatic software updates, a competitive edge, andsustainability. A cloud-based virtual queuing platform 3100 may comprisea web-based (e.g., mobile or desktop browser) or some otherInternet-based means (CLI, mobile and desktop applications, APIs, etc.)to create, manage, and analyze queues that may be accessed remotely bythe hosting entity 3102. A cloud-based virtual queuing platform 3100 maycomprise an application-based means to create, manage, and analyzequeues that may be accessed remotely by the hosting entity 3102.Entities 3102 may communicate to a cloud-based virtual queuing platform3100 via on-premise servers, the entity’s own cloud-based environment,desktop and laptop computing platforms, mobile platforms, and comparabledevices. Likewise, persons wishing to join, leave, or get the status ofa queue (other reasons may exist, e.g., transfer queues) may use anyelectronic means that the entity 3102 may use. Referring now to FIG. 32, entities 3102 and end-devices 3101 may communicate over a plurality ofcommunication networks (Internet, Satellite, PSTN, Mobile networks,Wi-Fi, BlueTooth, NFC, etc.) 3201 to a cloud-based virtual queuingplatform 3100.

The cloud based virtual queuing platform 3100 as described herein maymake use of the embodiments from the previous figures and referencedapplications by combining prior embodiments with at least one of the oneor more components from the embodiments described henceforth. Forexample, a cloud platform for virtual queuing 3100 may employ a callbackcloud 920 and/or user brands 910 as previously described to facilitateany features necessitated by the aspects of a cloud platform for virtualqueuing 3100 as disclosed herein. As a specific example, a callbackcloud 920 may handle the text and voice services used in a cloudplatform for virtual queuing 3100. Additionally, any previousembodiments may now implement the queue service 3200 as described in thefollowing paragraphs and figures. For example, previous embodiments aredirected towards call center applications. therefore, the queue service3200 and its aspects as described herein, may better facilitate thequeueing aspects of the call center embodiments or provide enhancementsnot disclosed in the previous embodiments.

FIG. 33 is a block diagram illustrating an exemplary system architecturefor a queue service 3200. According to one embodiment, A queue service3200 may make use of one or more, or some combination of the followingcomponents: a queue manager 3301, a queue sequencer 3302, a queue loadbalancer 3303, a prediction module 3304, a notification module 3305, asecurity module 3306, an analysis module 3307, and one or more databases3308.

A queue manager 3301 interfaces with entities and end-devices accordingto one embodiment. In another embodiment, a queue manager 3301 may use acallback cloud 920 to initiate messages and data flow between itself andentities and end devices. According to another embodiment, anotification module 3305 may take over notification functions toentities and end-devices. In yet another embodiment, a notificationmodule 3305 instructs a callback cloud 920 as to what messages to sendand when. According to an aspect of various embodiments, a notificationmodule 3305 may manage notifications to end-devices based on anotification escalation plan, whereby notifications a means aredynamically adjusted based on a set of rules. According to oneembodiment, a queue manager 3301 may handle the managing of a pluralityof simple queues without the need for the other modules 3302-3307, i.e.,if the simple queues require no authentication, security, analysis,predictions, and other aspects, then a queue manager 3301 may be allthat is required. The previously mentioned aspects may be implementedbased on a pricing scheme, according to one embodiment. A tiered-pricingcloud-based virtual queuing platform wherein the tiered pricing is basedoff the features available to the entities. According to one embodiment,a queue manager 3301 works in tandem with other modules 3302-3307 toprovide the full functionality of the features disclosed hereinspecifically in regards to handling sequences of queues.

Sequenced queues comprise two or more queues that are sequential,meaning at least one of the queues comes before another queue.Sequential queues may comprise parallel queues, meaning that one of thesequential queues is comprised of more than one queue for the sameevent. According to one embodiment, sequenced event queue management maybe handled by a queue sequencer 3302. Examples of sequenced events withassociated sequenced lines include air travel, zoos, concerts, museums,interactive galleries, theme parks, and any event with multiple requiredor optional queues. Sequential queues may not typically be treated witha first-in-first-out algorithm because the rate at which one personcompletes a queue may not be the same as a different person. Considerair travel; the first line (check-in) of a sequence of lines(subsequently at least security and then boarding lines) is checking inat an airport. A person with no checked baggage will make it throughfaster than a person with baggage to be checked; and a person whopreprinted their boarding pass is even faster.

The queue sequencer 3302 may be supplemented by a queue load balancer3303 that manages the load across a plurality of queues, parallel ornot, and sequential or not. The queue load balancer 3303 may takepredictions from a prediction module 3304 to better manage wait timesacross the plurality of queues. Continuing with the air travel example;a queue load balancer 3303 may distribute persons across queues for thesame event (multiple security queues, etc.) and may consider manyfactors. One factor may be distributing persons who all belong to asingle group into different parallel queues, so that the group mayfinish clearing the queue(s) more closely in time than had they allqueued at just one queue, rather than spread across multiple parallelqueues. Another factor may be the consideration of a route a person orgroup of persons has to take to make it to the first queue or asubsequent queue. Still more factors may be alerting the entity to openor close more queuing lanes or to produce more or less manual orautomatic scanners. A factor may also be to consider the estimated timeof arrival for some individuals and yet another factor may be whethersome individuals are willing to wait longer than others. In someembodiments the queue sequencer 3302 and queue load balancer 3303 workin tandem with the prediction module 3304 to run simulations of queuesin order to achieve the minimal wait times possible. Simulations mayhave goals other than minimal wait times, e.g., to maximize distancebetween persons during a pandemic.

As one example, expanding on the routing factor, a prediction module3304 may run simulations (using machine learning, according to oneembodiment) where the possible combinations of each queued person andthe possible wait-times of a sequence of queues is iterated over to findthe optimal configuration of persons across all queues. A specificexample may be a simulation which considers all the possible airlinecheck-in counters, their physical location in relation to one or moresecurity lines and each other, their historical check-in rates, thedistance to trams, buses, and the like, the passengers and therequirements of their check-in (baggage, wheelchair service, preprintedticket, groups size, etc.), when the passengers may arrive (using GPS orexplicit requests for estimated time of arrival and mode oftransportation), passenger walking rate (using sensors), departuretimes, and other factors such that the simulation produces an optimaltime-to-check-in notification to each passenger. Simulations may beconstrained not to create a perceptible unfairness to a queue. Forexample, putting a group of five people who just arrived in front of asingle person who has been waiting onsite for a significant amount oftime. This invention may also be used in air travel arrivals, expeditingbaggage claim processes and transportation services. These scenarios aremerely exemplary and not to be limiting in any way. Many factors existacross multiple domains and likewise for the types of constraints forsimulations.

According to various embodiments, a single queue is used for both walkup users scanning the QR code with a mobile device and users who book aspot in the queue using the web UI (e.g., webpage or webapp, etc.). Inthis case, users are in a single queue, however, the users who bookedonline have priority for that time slot they booked. So for instance, ifthe queue currently has a two hour wait time at 2 p.m., and a user booksa time slot for 3 p.m., when 3 p.m. approaches the user will beprioritized and will be notified to enter the physical queue. The queueload balancer 3303 and prediction module 3304 work together to accountfor these time slots, the total people per time slot, and factor it intothe predictive models to produce an accurate estimated wait time forwalk-ups joining the virtual queue, according to some embodiments. Inother words, if a user walks up and enters the virtual queue, theestimated wait time is taking into account all the users ahead of him orher including the ones in overlapping time slots. Additionally, if auser booked a time slot for 1 p.m. and the user shows up early at 12:30p.m. and scans the QR code, the user will be provided the queueestimated wait time and given the option (e.g., via an SMS message,email, messaging application, etc.) to keep the booked time slot orcancel the booked time slot and enter the queue like anyone else (thatway if the estimated wait time is less than 30 minutes, the user canenter the queue early and not have to wait around).

Factors described above and elsewhere herein may be informed and/orsupplemented using large or small data repositories (both private andpublic), streaming real-time (or near-real-time) data (e.g., traffic,etc.), sensor data, “Big Data”, and many other sources of data 3308.Another example from a separate domain is the emergency room (ER). Thevarious hospital departments/clinics, staffing, and procedures that gointo the ER service forms a complex logistical system that must beadhered to for regulatory and safety reasons. A queue service 3200 maybe used with a predictive medical prognosis module (not illustrated) orsimply data entries from front desk staff to prioritize patient queuing.Scheduling ER visits is also possible given the proper circumstances andmay reduce wait times. Scheduling appointments and managing walk-insspans multiple domains and is another factor that is considered by aqueue service 3200. According to another aspect, queued persons may pay,or use earned rewards that allow them to claim a more desirable positionin a queue. Persons may also be prioritized due to a class status, e.g.,gold member, age, etc.

According to some embodiments, the queue service 3200 and/or cloudplatform for virtual queuing 3100 may be configured to integrate withone or more internet-of-things (IoT) devices and/or sensors in order tofacilitate data exchange between the one or more IoT devices and sensorsand the queue service 3200 and/or platform 3100. In some embodiments,one or more IoT devices and/or sensors may be used to detect the numberof people in the physical queue and use that information in conjunctionwith queue load balancer 3303 and/or prediction module 3304 toautomatically adjust the throughput of the users being dequeued. Typesof IoT devices and/or sensors that may be used include, but are notlimited to, thermal sensors, pressure sensors, force sensors, vibrationsensors, piezo sensors, position sensors, photoelectric sensors,switches, transducers, and cameras. In some embodiments, received sensordata may be processed using one or more algorithms best suited forprocessing the particular type of data received from the sensor. Forexample, a camera may be set up to watch the queue and return live videodata to the queue service 3200, which may be configured to apply facialrecognition algorithms in order to determine the number of unique facesin the queue, and thus the number of individuals waiting in the queue.As another example, one or more pressure sensors may be deployed in thepath of the queue and when pressure is detected and the data sent toqueue service 3200, it may determine each set of pressure datacorresponds to a new individual entering or leaving the queue. In yetanother embodiment, multiple sensors of different types may be usedsimultaneously in order to determine the number of people waiting in aqueue. According to an embodiment, upon determination of the number ofpeople in a queue, queue service 3200 may automatically predict andadjust the queue wait times and subsequently the throughput of the usersbeing dequeued.

A security module 3306 may be used to generate QR codes, one-timepasswords, two-factor authentication codes, and the like. A securitymodule 3306 may automatically authentic queued persons at biometricstations, NFC stations, entity scanning devices, or use similartechnologies which may identify the uniqueness of a device or person. Asecurity module 3306 may receive an acknowledgement from an entity froma manual verification, or a verification using the entities ownequipment (using APIs as one example). A security module 3306 may reportthe success or failure of an authentication attempt to a 3^(rd) party,such as security forces or electronic alarm. The success or failure ofan authentication attempt may drive the next steps of one or morecomponents of a cloud based virtual queuing platform 3100. A securitymodule 3306 may monitor sensors that checks if the correct amount ofpeople enters a designated location. For example, a hotel may use thedisclosed invention to automate check-ins; where NFC beacons at thefront desk identify the person at the front desk by scanning the devicewhich would have been pre-registered with the guest’s profile and couldthen could trigger the release a locked compartment containing theguest’s room key and hotel information. Additionally, rules may beimplemented which do not allow the release of the locked compartment ifthe queued person’s turn was not up or has past.

An analysis module 3307 may provide statistical analysis of past,current (i.e., real-time), and future (i.e., predicted) queue metrics.FIG. 40 is exemplary graph output 4000 from an analysis module 3007illustrating the throughput of a queue during a half-hour timeframe.Over time machine learning could predict what throughput futuretimeframes may hold. FIG. 41 is another exemplary graph output 4100 froman analysis module 3007 illustrating a 10-minute time-block analysisfrom 4:00 AM to 1:00 PM of wait-times experienced in a queue,represented as different shadings (simplified for illustrativepurposes). Analysis reports may comprise metrics such as total parties,total people, average party size, average queue length, averagethroughput, average wait, and other comparable metrics.

FIG. 34 is a block diagram showing an exemplary use of a cloud-basedqueue service 3200, according to one aspect. Using the scenario of airtravel, a passenger or a group of passengers may approach a queue in anairport. At the beginning of the queue, a sign may be displayed such asthe one 3700 illustrated in FIG. 37 . Where the sign 3700 comprises a QRcode 3401 that auto generates a text message on the user’s end-device,and that text message is sent to a cloud-based queue service 3200 fromthe end-device and initializes the queueing service provided by theinvention. According to one embodiment, this sign could be scanned by asingle passenger or a group of passengers for a sequence of queues.According to one other embodiment, this sign could initialize thepassenger or group of passengers for a just one queue. According to yetanother embodiment, this sign may be scanned by just one passenger froma group of passengers for a single queue or a sequence of queues for thewhole group. According to another embodiment, this sign may be scannedby each passenger in a group of passengers for a single queue or asequence of queues. Once the QR code 3401 is scanned by an end-device3400, a text message 3402 may be automatically generated 3451 on thescanning device 3400. The end-device 3400 sends 3452 the text message toa cloud-based virtual queuing platform 3100. A cloud-based virtualqueuing platform 3100 updates 3453 the queue 3403 based on the receivedmessage 3402 and sends 3454 a confirmation notification 3404 back to theend-device 3400. As the reserved place in the queue approaches, furthernotifications 3405 are sent 3455 to the end-device 3400 based on a setof notification escalation rules. Once the queued person or personsarrive at the queue destination 3406, and having checked-in (andauthenticated their identity—or the end-device’s, according to someembodiments) at their designated time 3456, the queue 3403 may beupdated accordingly 3457.

Exemplary tables of notification escalation rules are illustrated inFIG. 44 and FIG. 45 . FIG. 44 is a table diagram showing an exemplaryand simplified rules-based notification escalation plan 4400. Thenotification type may be configured by the user, or by an administrator,or some combination thereof, based on the desired operating businessparameters. When a queued person is 20 minutes out, 10 minutes out, anddue to show for a queued reservation, the person’s end-device may benotified via their stored preferred communication method if present, orit may default to text-based notifications or some other communicationmeans. According to one embodiment, push notifications may be sent via abrowser or application. Should the queued person not show on time, theend-device may receive one last preferred reminder/notification. As timepasses, an IVR system may call the end-device and present the user witha series of options such as extending the time to show up by a fewminutes or to reschedule the time-slot. Should the IVR call fail, oraccording to some other parameter, an automated message may play overthe intercom if available. As a last resort, a call center agent mayplace an outbound call to the queued person’s end-device to try toresolve the tardiness issue. Call centers with call blendingcapabilities may make such outbound calls. This table is merelyexemplary and meant to convey just one scenario of rules. Manyconfigurations and implementations exist using various means ofcommunication and feedback mechanisms.

For example, FIG. 45 is a table diagram showing an exemplary andsimplified rules-based notification escalation plan that further useslocation data 4500. Using one or a plurality of sensors, the location ofa person may be known or predicted for some time in the future (i.e.,using map and traffic data and the end-device’s GPS as one example). Ifthe position in the queue is held at some time X, and the estimate timeof arrival—using location data—for said queued person is Y, then Time Δ= X - Y. Therefore, any negative value of Time Δ is a likely scenariothat a queued person will not show up at the expected time. Similarly,should Time Δ be a positive value, i.e., a person or group will show upearlier than expected a queue load balancer 3303 may reorganize queuedpersons to facilitate the early arrival. A rule set 4500 may be createdand applied for such situations. Other rule sets may be created forvarious aspects of the queuing procedure. Additionally, location datamay be used by a prediction module 3304 to predict the future locationof queued persons.

FIG. 35 is a method diagram illustrating the use of a cloud-basedvirtual queuing platform with an end-device, according to an embodiment.A cloud-based virtual queuing platform 3100 receives a request from anend device to join a queue 3500. The request may also be to leave aqueue if already slotted, or change places in a queue, or request moretime to get to the queue destination, change the party size, transferbetween queues, or to request the status of a queue. A cloud-basedvirtual queuing platform 3100 updates one or more queues based on thetype of request, i.e., based on at least one of the scenarios presentedabove 3501. Configuration changes may occur within components 910, 920,and 3301-3308 of a cloud-based virtual queuing platform 3100 based oncertain request scenarios. For example, a request for more time to reachthe destination if a person or persons is running late may cause a queueload balancer 3303 and/or a prediction module 3304 to adjust theiralgorithmic parameters, which in the end may still update the queues.

A confirmation will be sent back to the end-device to confirm asuccessful or failed request attempt 3502. Requests may also be sent tothe entity as desired or stored in a database or blockchain. Failed orsuspicious for requests may activate alarms or trigger securitysequences within a security module 3306.

Periodic updates may be sent to the end device, entity, or somecombination thereof 3503. As described previously, notifications, i.e.,periodic updates, maybe sent according to a rule set (e.g., notificationescalation plan). Notifications may be sent over any type ofcommunication means, any combinations of said communication means, andin any frequency as necessary.

Notifications may or may not adjust as the time nears when a queuedperson or persons should begin to move towards the queue destination3504. Adjustments may be as described above using notificationescalation plans. According to one embodiment, alerts may be sent overdevices that are not the end-device, such as an intercom or pagersystem. According to one embodiment, a prediction module 3304 usesrouting algorithms and machine learning to determine the amount of timeneeded for a person or persons to get to the destination in time. Therouting algorithms and machine learning not only considers the personwho is currently at the front of the queue, but may consider anycombination of persons across some or all queues and any combination ofsome or all persons in some or all queues.

A cloud-based virtual queuing platform 3100 is notified once the personor persons has checked in 3505. A successful notification may depend onwhether or not that person or persons have been successfullyauthenticated, according to one embodiment. Notification that theindividual or individuals have checked-in may update queues or triggerother actions according to the embodiments set forth herein.

One such update to the queue may be to remove the queued individual orindividuals, i.e., the individual’s or individuals’ end-devices, fromthe queue 3506. Should the individuals be in a sequential queue, thenthe individuals may be transferred to a different queue in addition tobeing removed from the queue they were previously in.

FIG. 36 is a method diagram illustrating another use of a cloud-basedvirtual queuing platform with an end-device, according to an embodiment.In this embodiment, follow-up text messages are sent to an end-device torequest further information. The information may be required or notdepending on the application. The information may be used to moreaccurately predict wait-times, slot the appropriate number of persons ina queue, or other queue-based parameters.

A group of travelers may scan a QR code 3401 as illustrated in the sign3700 in FIG. 37 , whereby after sending the automatically generatedrequest 3402/3600, the end-device receives a request for information inthe form of a text, as one example, from a cloud-based virtual queuingplatform 3100 as to the number of passengers in the group 3601. Acloud-based virtual queuing platform 3100 may then accumulate therequired number of slots 3603 from the reply 3602 in one or more queuesas calculated by the queue load balancer 3303. Like FIG. 35 explains, asequence of notifications 3604-3607 may then be sent to theend-device(s) and to the entity until the group has checked-in and hasbeen removed from the queue 3608.

FIG. 38 and FIG. 39 are block diagrams illustrating an exemplary mobileapplication (or web-based/browser-based according to one embodiment)used in bi-directional communication between a cloud-based virtualqueuing platform and an end-device, according to an embodiment. FIG. 38shows how a person may reserve a spot in a security checkpoint line fora group of 4 using a web-based or app-based mobile solution 3800. WhileFIG. 39 shows a confirmation screen following the reservation screen inFIG. 38 3900.

FIG. 42 is a flow diagram illustrating a web-based GPS aspect of acloud-based virtual queuing platform, according to an embodiment.According to one aspect of various embodiments, GPS is used to track aqueued person or persons and may also be used to predictestimated-time-of-arrivals and to then use that information todynamically adjust one or more queues. This figure illustrates just onemethod of gaining access to and implementing GPS functionality.

According to this embodiment, a URL is sent 4200 to an end-device thatdirects the end-device to a webpage that asks for access to theend-device’s location 4201. The URL may be sent by any number ofcommunication means (text, email, etc.). According to anotherembodiment, GPS access may be granted through a partnering applicationor a bespoke application.

The GPS data is then used at least by itself to determine the locationof the queued person 4202. If traveling in a group, an automated messagecould be sent to the tracked person asking if the whole group is presenttherefore providing location data for the whole group using one GPS. Thelocality data may be used with 3^(rd) party data (such as map andtraffic data, public transportation data, news, social media, and “Bigdata”) to make predictions and manage one or more queues. Predictionsusing the GPS and 3^(rd) party data may estimate the time of arrival fora plurality of people 4202. The plurality of data may be used to suggestspecific travel routes or incentives for some individuals so that theyarrive at a specific time in order to balance the queue load. Forexample, if the data shows a large influx of people are requesting orplan to arrive within a short time window, new route suggestions may besent to some individuals to increase the total travel time and discountsfor future events may be offered as an incentive. Continuing with thisexample, other individuals may be offered a coupon to a coffee shopwhich is on-route to the queue destination, in the expectation that somepercentage will take advantage of the coupon thus better balancing thequeue throughput for that high-influx time window. Other predictions anduses are anticipated using location data, sensors, 3^(rd) party data,and combinations thereof in order to better manage and balance one ormore queues.

In a first 4200 and second 4201 step, the URL is sent to an end-device4200 which leads to a browser that requests permission for the GPS 4201.The initial GPS reading skips steps 4202 and 4203 as they are “asnecessary”, and checks if the queued person is going to arrive on time4205. If the person is predicted to be on-time, then notifications aresent as normal, set by the notification escalation plan 4207. If theperson is not to be on-time and has not departed for the queuedestination 4206, then notifications will be sent according to thenotification escalation plan using those two parameters 4205/4205. Ifthe person will not be on-time but is in-route, then the queue may beupdated 4203 and if a prediction module 3304 determines a new (may beshorter, longer, or the same based on load balancing) route, the newroute is sent to the end-device 4204. It may also be the case that thedelay caused by the queued person requires some shifting of other queuedpersons, an incentive may be sent to one or more queued people 4204. Atsome point in time, given the queued person makes it to the queuedestination, he, she, or they will be checked-in 4208 and the queue maybe update appropriately 4209.

Referring now to FIG. 43 , steps 4300-4308 reflect the previous figure’ssteps, 4200-4208 respectively, with the exception that in a set ofsequential queues, a person or persons may be transferred to the nextsequential queue 4309, unless that queue was the last in the sequence.It is also correct to declare that FIG. 42 may be applied to sequentialqueues as a person or persons would inherently be removed from aprevious queue in a sequence of queues after being transferred to thenext queue in the same sequence.

FIG. 46 is a message flow diagram illustrating the exchange of messagesand data between components of a cloud-based virtual queuing platformused in sequential event queue management, according to an embodiment.An initial check-in message is received by a queue manager 3301.Automated texting and callback technology may be triggered to ask one ormore follow up questions to get more information. The follow upquestions may be required or optional. A prediction module 3304 uses theavailable information to make the best check-in time recommendations,the amount of time needed to clear each queue, and so forth. Therequesting party may then be placed in the first queue in the sequencebased on the operating parameters (either by recommendations or explicitrequests). The queue sequencer 3302 sends updated queue information tothe queue manager 3301 which may trigger periodic notifications to besent to the party.

A queue load balancer 3303 uses real-time queue information from a queuesequencer 3302 and predictions from a prediction module 3304 to keep thewait times to a minimum across the plurality of queues. The queue loadbalancer 3303 may be configured to prioritize other goals instead asdisclosed elsewhere herein. As also disclosed elsewhere, the queue loadbalancer 3303 may use detours, incentivized delays, and coupons toadjust the flow of traffic through an event, both spatially and/ortemporally. For example, a virtual event may not have spatialrestrictions but network congestion restrictions, wherein queued personsmay be presented with advertisements or media to control the flow of thequeue. These aspects may be optional for queued persons with incentivesto choose to wait longer than others, such as the airlines industry doeswhen a flight is overbooked.

Once the party has checked-in to the first line successfully, the partyis slotted into the next sequential queue. Throughout the wholesequential queue process, the queue load balancer 3303 is maintainingthe optimal wait time configuration. This process of checking-in,maintaining bi-directional communication with the party (i.e.,end-device), and maintaining optimal wait times is iterated through eachline until the party clears the final queue.

An additional aspect of various embodiments employing sequential queuesis creating a unique identification object for each individual or group.This unique identification object may be used in managing the individualor group across the sequence of queues. The unique identification objectmay comprise end-device uniquely identifying numbers such as MACaddresses, EIN numbers, customer numbers, phone numbers, and the like.

FIG. 47 is a flow diagram illustrating a load-balancing aspect of acloud-based virtual queuing platform, according to an embodiment. Thisfigure illustrates only one algorithmic aspect of a load balancer 3303.This aspect is the balancing of parallel queues, wherein parallel queuesare queues all leading to the same outcome/destination.

In a first step 4700, the average wait time (wait time(s) could also bemeasured against some other parameter, e.g., even if one queued personhas to wait more than X minutes, etc.) is compared a set thresholdlimit. If the average wait time has not surpassed the limit, then theoperation continues as normal 4701. If the limit has been surpassed,then it is determined if a new queue is available 4702. This may beaccomplished by storing entity profiles in a database, having suchinformation as how many queues (or check-in stations) may beestablished. This applies for many aspects of the entity. According toone embodiment, entities may be sent automatic messages requesting suchinformation if it is not known. If it cannot be established that anotherqueue is possible, or that another queue is not possible, thenincentives may be sent out to a calculated set of queued persons 4704 ifavailable 4703. If not, then at least a notification is sent out to theeffected parties, including the entity in some embodiments 4705.

If a new queue may be established or an already existing parallel queuedoes not exist 4706, then the entity is notified to establish (e.g., mana check-in counter, place or power on an automated check-in means) aparallel queue 4707. That is unless the entity does not need to performany actions to instantiate a parallel queue. According to oneembodiment, a cloud-based virtual queuing platform may send anelectronic signal instantiating a new check-inapparatus/destination/virtual or physical point. For example, theelectronic signal may turn on a “lane open” sign and boot an NFC beaconwithin a turn-style. If it so happens that a turn of events in-fact doesnot lead to wait times under the threshold, the effected parties may benotified 4705. However, it is likely that this algorithm combined withthe other factors calculated by a cloud-based virtual queuing platform,i.e., the iterative queue simulations solutions, will provide adecreased average wait time. If it is determined that adding a new queue(or that an already existing queue is not at capacity) 4708 thannotifications may be sent instructing individuals and groups to adjustaccordingly 4709. The cloud-based virtual queuing platform may beconfigured to allow an individual or group of individuals to book a timeslot in a queue using a mobile device (e.g., smartphone, tablet, smartwearable, etc.); the individual or group can overflow into another queueif it has availability. For example, if two airlines use the same gate,but different security checkpoints, and there is availability at onecheckpoint and not the other, the platform can automatically overflowthe individual or group to the other checkpoint so they can still bookthe desired virtual queue time slot. In such a case, a notification maybe sent to individuals who have been ‘overflowed’ via variouscommunication channels including, but not limited to, SMS, email, andother messaging applications (e.g., WhatsApp, etc.).

Not shown in this diagram are other considerations such as the economiccost of operating additional queues, pandemic considerations such asseparating persons by vaccination-status, and other queue-relatedconsiderations. According to some embodiments, the wait time threshold4700 may be compared against the time decreased by adding additionalqueues 4708, and if the wait time difference is significant enough,shuffle queued people around 4707 regardless of if the new wait time4708 is under the threshold 4700.

Load balancing mechanisms comprise: an alert to an entity to open a newqueue; sending a new route to a queued person who is enroute, the newroute increasing or decreasing the travel time; a digital coupon for abusiness or location that results in the queued person delaying his orher position in the queue; a message to a queued individual, the messagecomprising an opportunity to experience a person, place, or thing thatlikewise results in a delay; and an incentive for a queued individual tochange positions with another queued individual, and other similarmechanisms that may delay, distract, incentivize, and entertain queuedpersons.

FIG. 48 is a method diagram illustrating a one-time password aspect in acloud-based virtual queuing platform, according to an embodiment. Thisfigure illustrates one method of implementing an authentication feature.The authentication in this example is a one-time use password that isgiven to the end-device and to the entity. According to one aspect, thepassword is only given to the end-device after a successful biometricauthentication. According to another aspect, the entity is a businessdevice that a business user uses to manually verify the password withthe queued person. For example, a one-time password may be sent to boththe queued person and the entity via text, email, or the like. Uponarrival, the queued person reads the one-time password to the businessemployee. According to one other aspect, the business employee may senda reply message back to a cloud-based virtual queuing platformconfirming the queued person checked-in successfully. According to oneaspect, the entity is an electronic device that is capable of verifyingthe one-time password such as a kiosk.

According to a first step 4800, a cloud-based virtual queuing platformreceives a request for an appointment or a position in a queue. Requestsmay be other actions such as to leave a queue, etc. In a second step,the virtual queue may be updated based on the request 4801. A third stepcomprises sending a notification of appointment confirmation withone-time password to both an entity and a queued end-device 4802.Periodic updates may be sent to the end-device per a rule set 4803. In afourth step 4804, an alert is sent to end-device (and the entity in someembodiments) to notify individual their turn is coming up or is up.Individuals are then authenticated using the onetime password via atleast one of the implied or explicit methods disclosed herein. Anotification of successful check-in may be automatically sent from anentity device or manually sent which is received by the cloud-basedvirtual queuing platform 4805. In a sixth step 4806, the end-device isremoved from the virtual queue.

FIG. 49 is a block diagram illustrating an exemplary system architecturefor a queue manager 4900 with task blending and accumulation, accordingto an embodiment. According to various embodiments, a queue manager4900, features the same functions as in previous embodiments disclosedherein, and further comprises a task blending service 4901 and anaccumulation service 4902. Task blending 4901 is an improved version ofcall blending found in some call centers. Call blending gives theability to deliver both inbound and outbound calls seamlessly to anagent, regulating outbound call volume based on inbound traffic. Wheninbound traffic is low, outbound calls are automatically generated for aspecified campaign. When inbound traffic picks up, the dialerdynamically slows the number of outgoing calls to meet the inboundservice level. Task blending further improves upon this by additionallyredirecting computational resources for other tasks when queuethroughput is low. According to various embodiments, callback clouds andcloud-based virtual queuing platforms as disclosed herein may comprisecomponents that employ call blending or task blending.

Referring now to FIG. 50 and FIG. 52 ), to begin the implementation of atask blending service, queue throughput should be modeled historicallyand/or predicted 5200. For example, FIG. 50 illustrates a queuethroughput between the hours of 4AM and 8PM 5000. With a future queuethroughput modeled 5001, low throughput times may be identified5002-5004 and used for call blending and task blending. According to oneaspect, queue throughput may be modeled in real time, using calculus toderive instantaneous rates of change that may show the queue flow rateis decreasing.

According to one embodiment, low throughput queue flow may be used totrigger the reallocation of computational resources that were previouslyused for real-time queue simulations—see at least prediction module 3304features in previous figures—for queue-configuration optimizationsimulations 5201. Real-time queue simulations refer to optimizingpersons in a queue where the queue configuration is already established.Queue-configuration optimization simulations on the other hand usesqueue theory to make recommendations physically and logistically forqueues 5202. It is possible to implement recommended queuereconfigurations while persons are in a queue, but this is notrecommended from a customer service standpoint. Furthermore,queue-configuration optimization simulations employ queue theory as wellas other considerations. For example, a consideration of the queue’sphysical layout in space, the queue’s possible physical arrangements,and the queue’s physical relations to other queues. According to oneaspect, determining optimal placement and configurations of many queuesmay be computationally intensive because it is similar to approximatingsolutions for the traveling salesman dilemma.

Queue theory optimized simulations may make use of Little’s rule whichprovides the following results:

L=λW ; L_(q) = λW_(q)

Where λ is the mean rate of arrival and equals 1/E[Inter-arrival-Time],and where E[.] denotes the expectation operator. W is the mean waitingtime in the system. L_(q) is the mean number of customers in the queue.W_(q) is the mean waiting time in the queue. The first part of the aboveapplies to the system and the second half to the queue, which is a partof the system.

Another useful relationship in the queue is:

W=W_(q)+μ

Where µ is the mean service rate and equals 1=E[Service-Time]. The aboveprovides the mean wait in the system which is the sum of the mean waitin the queue and the service time (1/µ).

Furthermore, queue theory makes use of at least 4 models as illustratedin FIG. 51 . In FIG. 51 , there are four models each with an arrow 5101representing arrivals, a series of circles representing a queue 5102,one or more service facilities 5103-5106, and a departure arrow 5107.The first model is a single-channel, single-phase system 5100 a. Thesecond model is a single-channel, multi-phase system 5100 b. The thirdmodel is a multi-channel, single-phase system 5100 c. The fourth modelis a multi-channel, multi-phase system 5100 d.

Queue theory (the equations and queue models), physical restrictions,physical relations, and other queue data is used to simulate the optimalconfiguration of one or more queues 5202. The results of the pluralityof simulation are analyzed for the optimal configurations 5203. Thesesimulations may be provided a set of parameters by host entities.Produced recommendations are delivered via the various communicationmethods disclosed herein, e.g., web-based, app-based, text, etc. 5204.Queue-configuration optimization simulations may be computed at anytime, not just during off-peak queue times. However, if resources arelimited, task blending may be appropriate.

An accumulation service 4902 functions to supplement disclosed queuemanagement processes by best reserving discrete positions in a queue fora group. For example, a group of 12 requests placement in a virtualqueue, but the virtual queue may not have 12 continuous spots— for avariety of reasons. An accumulation service 4902 will reserve openspots, i.e., accumulate available positions in the queue, until therequest is fulfilled. An accumulation service 4902 may call to a queueload balancer 3303 to rearrange persons to expedite the accumulation.This may mean adjusting select individuals for detours or incentives.Another method may be to increase or decrease the current wait time forpersons queued back-to-back so that a new slot may be inserted betweenthem.

FIG. 53 is a method diagram illustrating an accumulation service used ina cloud-based virtual queuing platform, according to an embodiment. Anaccumulation 4902 service receives a request to join waitlist from agroup 5300 and sends a request acknowledgment to the group once received5301. Queue positions are accumulated until the group size is fulfilled5302. Accumulated positions are associated with a group object 5303 sothe group object may be used in computational methods such assimulations of machine learning neural networks. A confirmationnotification is sent to the group when all positions are finishedaccumulating 5304. Periodic updates are sent to the group as outlined insimilar embodiments disclosed herein 5305. An alert is sent to notifythe group their turn is up, or is coming up 5306. Notifications of thegroup’s check-in status may be sent at the initial check-in, during thecheck-in process (e.g., how many of the 12 how so far processedthrough), and upon completion of the check-in process 5307. The groupmay now be removed from the virtual queue 5308.

FIG. 54 is a block diagram illustrating an exemplary system architecturefor a machine learning prediction module 5400 based on queue theory andpsychology, according to an embodiment. According to variousembodiments, a prediction module 5400 features the same functions as inprevious embodiments disclosed herein, and further comprises a machinelearning model 5401, a database comprising queue theory and queuepsychology rulesets 5402/5403, and a database for storing entity data5404. Data may be combined into one database, a plurality of localdatabases, or a distributed datastore, or some combination thereof. Manyembodiments are anticipated providing various predictions for aplurality of desired parameters. Predictions may be estimated wait times5412 or configuration recommendations for past, current, or futurequeues 5413.

Predictions for are generated using machine learning models 5401.Machine learning disclosed herein comprises machine learning models usedfor: learning problems such as supervised learning, unsupervisedlearning, and reinforcement learning; hybrid learning problems such assemi-supervised learning, self-supervised learning, multi-instancelearning; statistical inference models such as inductive learning,deductive inference, and transductive learning; and learning techniquessuch as multi-task learning, active learning, online learning, transferlearning, and ensemble learning. The machine learning model ingestsexplicit parameters from the entity such as max wait times, hours ofoperation, and other operating parameters 5405. Also ingested is anyhistorical data available about the queue from the entity 5406, such asoperating costs, wait times in relation to days of the week or months ofthe year, and other historical data. Historical data originating from acloud-based virtual queuing platform may also be stored in an entitydatabase 5404 and used in predictive modeling. Spatial data 5407, thephysical layout and constraints of a queue, may be provided by an entityor collected from dispatched agent, or from a 3^(rd) party scan. Spatialdata 5407 allows a simulation to know the spatial limits of possiblequeue configuration parameters such as distances, seating arrangements,hybrid physical/virtual queuing, etc. Incentives data 5408 is datarelating to possible incentives that may be offered to queued personssuch as coupons, discounts on future visits, sightseeing stops,entertainment, and other events meant to delay a queued person whilemaintaining his or her satisfaction. Incentives data 5408 may also be a3^(rd) party service that is accessed by an API or other communicationmeans. Incentives data 5408 may comprise positional data so thepredictive modelling can account for which incentives are relevant.Other data from an entity or an area where an entity is operating maycomprise sensor data, wherein sensors comprise vision and imagingsensors, temperature sensors, radiation sensors, proximity sensors,pressure sensors, position sensors, photoelectric sensors, particlesensors, motion sensors, metal sensors, level sensors, leak sensors,humidity sensors, gas and chemical sensors, force sensors, flow sensors,flaw sensors, flame sensors, electrical sensors, contact sensors, andnon-contact sensors.

3^(rd) party data may also be retrieved as needed by a prediction module5400 such as environment data, e.g., weather, local news reports, etc.5409 which may inform the predictive learning model 5401 as to obstaclesqueued persons may experience. Routing data 5410 comprises traffic datathat may be used determining the arrival times of a queued person whohas an appointment for a later time, as one example. Detour data 5411 issimilar to incentives data 5408 but is not an explicitly maintaineddatabase of redeemable media used for delaying an individual, it isdatabase comprising possible attractions, shopping experiences, andother detours in a local area that may be used to delay a queuedindividual. More specifically, Incentives data 5408 is typicallyredeemable experiences that were agreed upon between two or more partiesfor the explicit purpose of delaying a queued person. Where Detour data5411 may be museums, craft breweries, coffee shops, outlet malls, andthe like which there is no redeemable object. All the 3^(rd) party data5409-5411 may be used in various predictions and configurationsimulations. It can be appreciated that a queue which experiences boutsof low activity then bursts of high activity may benefit from a locationnearer to incentives (e.g., shopping, dining, etc.) for load balancingefforts, e.g., consider queues on a cruise ship, amusement parks,airports, etc.

FIG. 55 is a flow diagram illustrating an exemplary queue configurationmethod used in a cloud-based virtual queuing platform, according to anembodiment. Data as described in the previous figure is received from anentity which relates to one or more queues 5500. That data may be storedin an entity database, wherein each entity has a profile that data maybe associated with 5501. A prediction module retrieves 3rd party datarelevant to the queue such as weather, local reports, traffic, etc.5502. A trained machine learning model ingests the entity data and the3rd party data 5503 in order to create a plurality of queueconfiguration simulations 5504. Queue theory and queue psychologymethods are applied to the above data by the machine learning model suchthat a plurality of simulations is produced 5504. The plurality ofsimulations is analyzed for the optimal queue configuration 5505.Optimal configurations may be based off a myriad of desired outcomes;such as the simulation with the least wait time, or the simulation withthe least distance a queued person must travel, or the simulation withwherein the queue occupies the least amount of space while maintainingat least 6 feet of separation between queued persons, or the simulationwith the least amount of cost to an entity hosting a physical queueassociated with the virtual queue, or the simulation with the least costto the queued persons, or the simulation which allows for the maximumwait time without disinteresting a person from joining a queue.Determine a difference between the current queue configuration and theoptimal queue configuration 5507. Output the difference as a queuerecommendation 5508.

FIG. 56 is a flow diagram illustrating an exemplary wait-time predictionmethod used in a cloud-based virtual queuing platform, according to anembodiment. According to one method, receive data from an entity relatedto a queue 5600, store the received data in an entity database 5601,simulate a plurality of queue combinations using the data, queue theory,and queue psychology 5604, analyze the plurality of simulations for themost probable queue combination 5605, determine the wait times in themost probable queue combination simulation 5607, and output thepredicted wait times 5608.

FIG. 57 is a block diagram illustrating an exemplary system forproviding enhanced queue management with access control, according to anembodiment. According to the embodiment, the system comprises a queueservice 5700 comprising at least queue manager 5702, security module5704, and queue load balancer 5706. Queue service 5700 is configured forbidirectional communication with a plurality of systems 5720 and eachsystem has a plurality of sensors 5721 disposed at the location of thecorresponding system. At queue service 5700 queue manager 5702 canreceive a user request 5715 from a user device 5710 to join a virtualqueue representing a physical queue for one or more systems 5720. Uponreceipt of the user request to join the virtual queue, queue manager5702 assigns the user to a position in the virtual queue. In someimplementations, queue service 5700 can generate and send a notificationto the user device 5710 informing the user that their request has beenreceived, their current queue position, and an estimated wait time, ifapplicable. Security module 5704 may then transmit an access key 5725 tothe user device 5710 which, when certain conditions are satisfied,allows the user to access one or more of the controlled systems 5720.The system is advantageous because it allows a virtual queue tocompletely replace a physical queue associated with a system byautomating queue management processes and access control based on sensordata, queue position, and user data.

Queue service 5700 can communicate with each system and sensor groupusing an appropriate communication network such as, for example, theInternet. Systems1-N may represent either physical or virtual systems.Systems1-N can represent controlled systems which require an access keyto interact with said systems. Each of systems1-N may representdifferent locations or systems that are independent of each other suchas, for example, wherein system 1 represents door locks associated witha rental property and system 2 represents a tee shirt printing shop on aboardwalk. Each of systems1-N may represent different systems at a givenlocation or venue such as, for example, wherein system 1 represents afirst attraction at a theme park and system 2 represents a secondattraction at a theme park.

Each sensor group may be associated with a system and configured tomonitor queue conditions by continuously gathering queue state data.Sensor group 1 5721 may comprise a plurality of sensors including, butnot limited to, pressure sensors, cameras, microphones, thermal sensors,biometric sensors, force sensors, position sensors, temperature sensors,vibration sensors, piezo sensors, humidity sensors, NFC beacons,Bluetooth sensors, RFID sensors, photo optic sensors, and/or the like.The sensors may be placed in positions relative to the system ofinterest most advantageous to acquiring useful data for the purpose ofmonitoring the queue state. Sensor data may be received by queue manager5702, security module 5704, and/or queue load balancer 5706 in order toexecute various tasks to support virtual queue management and accesscontrol to systems1-N.

Security module 5704 may be a specifically configured version ofsecurity module 3306 (referring to FIG. 33 ). Security module 5704 maybe used to generate access keys, QR codes, one-time passwords,two-factor authentication codes, and the like. Access keys 5725 may begenerated and sent to a requestor’s device 5710. Security module 5704may automatically authenticate queued persons using various sensors suchas at biometric stations, NFC stations, entity scanning devices, or usesimilar technologies which may identify the uniqueness of a device orperson. Security module 5704 may monitor sensors that check if thecorrect amount of people entered a designated location. For example, ahotel may use the disclosed invention to automate check-ins; where NFCbeacons at the front desk identify the person at the front desk byscanning the device which would have been pre-registered with theguest’s profile and could then could trigger the release a lockedcompartment containing the guest’s room key and hotel information.Additionally, rules may be implemented which do not allow the release ofthe locked compartment if the queued person’s turn was not up or haspast. Security module 5704 may grant a user access to a controlledsystem if the user has an access key and if the user is at the firstposition in the queue.

Queue load balancer 5706 may be a specifically configured version ofqueue load balancer 3303 (referring to FIG. 33 ). Queue load balancer5706 can calculate current queue throughput for a plurality of virtualqueues associated with controlled systems and compare the currentthroughput with a predicted or simulated queue throughput based ondetected events and reassign users based on that comparison. A queueevent may be detected by analyzing sensor data associated with a virtualqueue representing physical queue for a controlled system. Queue eventsmay comprise other queue join requests, requests to leave a queue,additional queues opening/closing, system state changes (e.g., a themepark attraction being closed for maintenance, etc.), and/or the like. Insome embodiments, there may be defined rules associated with variousqueue events which can be used by queue load balancer 5706 and/or queuemanager 5706 when performing actions related to queue reassignment. Insuch cases, the defined rules may be stored in a database and retrievedduring operation as required to categorize and/or analyze detectedevents.

FIG. 58 is a message flow diagram illustrating an exemplary exchange ofdata messages between and among various components of a system forenhanced virtual queue management with access control. According to someembodiments, a user of a user device 5710 can submit a request to join avirtual queue 5805 to queue manager 5702. In response queue manager 5702can send a notification to the user 5810 alerting them that theirrequest has been received, their position in the queue, and an estimatedwait time, if applicable. Once a user has been added to the queue andassigned a position, security module 5704 can send an access key 5815 tothe user device. The access key can provide the user access to acontrolled system which may be a physical system (e.g., lockbox) orvirtual system (e.g., restricted software). Simultaneously andcontinuously, queue manager 5702 and queue load balancer 5706 monitorthe queue state. Sensor array 5721 can send queue state data 5820 (e.g.,various sensor data) to queue manager 5702 and/or queue load balancer5706. Queue manager 5702 can receive the queue state data and determineif an event has been detected 5825 and if it has then the event data canbe sent 5830 to queue load balancer 5706 which can use the received datato determine if the user is to be reassigned to a different queue basedon the event data. If a reassignment is determined to be necessary, thenqueue reassignment data 5835 can be sent to queue manager 5702 which canupdate the queue position and pass the updated queue position 5840 tothe user device 5710. At user device 5710, if the received queueposition indicates that the user is at the first position (e.g., frontof the queue), then the user may be granted access 5845 to a controlledsystem via the access key. The access key only works to grant access tothe controlled system if the user’s current position in the virtualqueue is the first position. Sensors associated with the controlledsystem may be used to locate, identify, receive, retrieve, or otherwiseobtain the access key from user device 5710 using methods known to thoseskilled in the art. For example, if the access key was an NFCtransmitted to user device 5710, then an NFC reader located near andconfigured for the controlled system can read the NFC when the userpresents it via their device.

FIG. 59 is a flow diagram illustrating an exemplary process formonitoring a virtual queue and reassigning queue positions baseddetected events, according to an embodiment. According to theembodiment, the process begins as step 5902 when queue manager 5702receives a request to join a virtual queue from a user via a userdevice. The virtual queue may replace the need to have a physical queueat a location or for a controlled system by allowing a plurality ofusers to virtually queue and be alerted via their user devices when theyhave reached the front of the queue. The request to join the queue maycomprise information related to the request such as information whichdescribes which event, system, venue, process, item, or service that theuser is requesting to be queued for, time constraints, user location,user device metadata, and various other types of information that may beuseful for queue manager 5702 to fulfill the request. The user devicemay be a mobile device such as a smart phone, smart wearable, tabletcomputer, laptop, or some other similar mobile computing device. Theuser may submit a request to join a virtual queue via a dedicatedsoftware application stored and operating on the user device or it maybe submitted via a web application accessible through the Internet viathe user device.

Upon receipt of the user request to join a virtual queue, queue manager5702 assigns a queue position to the user at step 5904. An alert may begenerated by queue manager 5702 and sent to the user device notifyingthe user that their request has been received and may further indicateto the user their current queue position and an estimated wait time, ifapplicable. While the user is in the virtual queue, queue manager 5702continuously monitors the queue state of the queue which the user hasbeen assigned at step 5906 in order to detect events as they occur. Insome implementations, queue manager 5702 can monitor the queue state byreceiving various data from a plurality of sensors that are disposed atthe location where the physical queue which the virtual queue replacedis located. Sensor data may comprise information related to thelocation, weather, network, other devices, and/or the like. The sensorsmay provide information to queue manager 5702 which can be indicative ofvarious events that may lead to queue reassignment based on the type ofdetected event. Some non-limiting exemplary queue events can includeother join requests either from a same user or a plurality of otherusers, requestors leaving a queue, or the opening/closing of additionalqueues. If a queue event is not detected at 5908, then queue manager5702 continues to monitor the queue state until an event is detected.When an event is detected at 5908 queue load balancer 5706 may calculatea new current queue throughput based on the detected event at step 5910.At step 5912, queue load balancer 5706 compares the current queuethroughput with a predicted queue throughput to determine a newestimated wait time which can be sent to the user via user device tonotify the user of any change in wait time. Based on the detected eventand on the comparison of the current and predicted queue throughputsqueue manager 5702 may determine that the user should be reassigned.Reassignment may be related to the assignment of the user to a newvirtual queue. Reassignment may be related to the assignment of the userto a new position in virtual queue which the user is already in. Ifreassignment is not necessary at 5914, then queue manager 5702 continuesto monitor the queue state to detect a queue event. If, instead,reassignment is to be carried out, then queue manager 5702 assigns theuser to a new queue or queue position.

FIG. 60 is a flow diagram illustrating an exemplary method for managinga virtual queue for a controlled system, according to an embodiment.According to the embodiment, the process begins at step 6002 when queuemanager 5702 receives a request to join a virtual queue from a user viaa user device. The virtual queue may replace the need to have a physicalqueue at a location or for a controlled system by allowing a pluralityof users to virtually queue and be alerted via their user devices whenthey have reached the front of the queue. The virtual queue acts asaccess control for virtual or physical systems. For example, physicalcontrolled systems may be door locks at a rental unit or computer loginsfor a network or software. Further, virtual controlled systems such asaccount access may be provided by the virtual queueing capabilitiesdescribed herein such as by controlling access to specificauthentication privileges associated with one or more accounts. Therequest to join the queue may comprise information related to therequest such as information which describes which event, system, venue,process, item, or service that the user is requesting to be queued for,time constraints, user location, user device metadata, and various othertypes of information that may be useful for queue manager 5702 tofulfill the request. The user device may be a mobile device such as asmart phone, smart wearable, tablet computer, laptop, or some othersimilar mobile computing device. The user may submit a request to join avirtual queue via a dedicated software application stored and operatingon the user device or it may be submitted via a web applicationaccessible through the Internet via the user device.

Upon receipt of the user request to join a virtual queue, queue manager5702 assigns a queue position to the user at step 6004. An alert may begenerated by queue manager 5702 and sent to the user device notifyingthe user that their request has been received and may further indicateto the user their current queue position and an estimated wait time, ifapplicable. At step 6006, security module 5704 provides an access key tothe requestor’s device. The access key may provide the user with accessto the controlled system for which the virtual queue is associated withwhen other conditions are met. For example, one such condition may bethat the user is at the first position in the queue (i.e., at the headof the queue or position one). The access key may be in various forms ortypes dependent upon the embodiment. For example, in some embodiment theaccess key may be an NFC sent to the user device and an NFC beaconlocated at the controlled system may grant access to the user when theuser has reached the front of the queue and moved within range of theNFC beacon. In another example, the access key may be a unique deviceidentifier assigned to the user device and transmitted via Bluetooth orWiFi to a nearby kiosk or security module 5704 located at the controlledsystem which verifies the received unique device identifier and grantsaccess to the controlled system. In yet another embodiment, the accesskey may be associated with biometric data of the requestor such as avoiceprint, a fingerprint, an iris scan, and/or the like. In suchembodiments, a sensor array may comprise one or more biometric scannersconfigured to scan a requestor to identify the biometric access key.

Security module 5704 may communicate with a plurality of sensorsdisposed at the controlled system in order to monitor queue position andto verify users for access control processes. At step 6008 both queuemanager 5702 and security module 5704 may receive, retrieve, orotherwise obtain sensor data in order to monitor queue state conditions.For example, sensors may be used to monitor the position of people inthe queue or to monitor users as they access the controlled system. Ifat 6010 the a user has not reached the front position of the queue, thenqueue manager 5702 continuously monitors the queue state. If at 6010 theuser has reached the first position in the queue, then an alert may begenerated and sent to the user’s device notifying the user that theyhave reached the front of the queue and they may now access thecontrolled system. At step 6012 security module 5704 and/or queuemanager 5702 can provide user access to the controlled system byreceiving, retrieving, or otherwise obtaining the access key from theuser device when the user is at first queue position. For example, ifthe access key was an NFC which was sent to the user device and there isan NFC beacon located at the controlled system, then even though theuser has the access key on their device, the NFC beacon would only grantaccess to the user when they are in the first position. Therefore,access only works when requestor’s position in the queue is up (e.g.,first position). Furthermore, using the system and methods describedherein a single login may be used for multiple because the access keyonly works on a user’s device when the reach the front of the queue,which results in a per-queue login instead of per-user. This isadvantageous because only a single login is required to be generated andmaintained, which reduces system latency by reducing the amount ofinformation that needs to be retrieved and verified.

The process and/or flow diagrams described herein do not necessarilyimply a fixed order to any depicted actions, steps, and/or procedures,and embodiments may generally be performed in any order that ispracticable unless otherwise and specifically noted. Any of theprocesses and/or methods described herein may be performed and/orfacilitated by hardware, Software (including microcode), firmware, orany combination thereof. For example, a storage medium (e.g., a harddisk, Universal Serial Bus (USB) mass storage device, and/or DigitalVideo Disk (DVD)) may store thereon instructions that when executed by amachine (such as a computerized processing device) result in performanceaccording to any one or more of the embodiments described herein.

Hardware Architecture

Generally, the techniques disclosed herein may be implemented onhardware or a combination of software and hardware. For example, theymay be implemented in an operating system kernel, in a separate userprocess, in a library package bound into network applications, on aspecially constructed machine, on an application-specific integratedcircuit (“ASIC”), or on a network interface card.

Software/hardware hybrid implementations of at least some of the aspectsdisclosed herein may be implemented on a programmable network-residentmachine (which should be understood to include intermittently connectednetwork-aware machines) selectively activated or reconfigured by acomputer program stored in memory. Such network devices may havemultiple network interfaces that may be configured or designed toutilize different types of network communication protocols. A generalarchitecture for some of these machines may be described herein in orderto illustrate one or more exemplary means by which a given unit offunctionality may be implemented. According to specific aspects, atleast some of the features or functionalities of the various aspectsdisclosed herein may be implemented on one or more general-purposecomputers associated with one or more networks, such as for example anend-user computer system, a client computer, a network server or otherserver system, a mobile computing device (e.g., tablet computing device,mobile phone, smartphone, laptop, or other appropriate computingdevice), a consumer electronic device, a music player, or any othersuitable electronic device, router, switch, or other suitable device, orany combination thereof. In at least some aspects, at least some of thefeatures or functionalities of the various aspects disclosed herein maybe implemented in one or more virtualized computing environments (e.g.,network computing clouds, virtual machines hosted on one or morephysical computing machines, or other appropriate virtual environments).

Referring now to FIG. 26 , there is shown a block diagram depicting anexemplary computing device 10 suitable for implementing at least aportion of the features or functionalities disclosed herein. Computingdevice 10 may be, for example, any one of the computing machines listedin the previous paragraph, or indeed any other electronic device capableof executing software- or hardware-based instructions according to oneor more programs stored in memory. Computing device 10 may be configuredto communicate with a plurality of other computing devices, such asclients or servers, over communications networks such as a wide areanetwork a metropolitan area network, a local area network, a wirelessnetwork, the Internet, or any other network, using known protocols forsuch communication, whether wireless or wired.

In one embodiment, computing device 10 includes one or more centralprocessing units (CPU) 12, one or more interfaces 15, and one or morebusses 14 (such as a peripheral component interconnect (PCI) bus). Whenacting under the control of appropriate software or firmware, CPU 12 maybe responsible for implementing specific functions associated with thefunctions of a specifically configured computing device or machine. Forexample, in at least one embodiment, a computing device 10 may beconfigured or designed to function as a server system utilizing CPU 12,local memory 11 and/or remote memory 16, and interface(s) 15. In atleast one embodiment, CPU 12 may be caused to perform one or more of thedifferent types of functions and/or operations under the control ofsoftware modules or components, which for example, may include anoperating system and any appropriate applications software, drivers, andthe like.

CPU 12 may include one or more processors 13 such as, for example, aprocessor from one of the Intel, ARM, Qualcomm, and AMD families ofmicroprocessors. In some embodiments, processors 13 may includespecially designed hardware such as application-specific integratedcircuits (ASICs), electrically erasable programmable read-only memories(EEPROMs), field-programmable gate arrays (FPGAs), and so forth, forcontrolling operations of computing device 10. In a specific embodiment,a local memory 11 (such as non-volatile random access memory (RAM)and/or read-only memory (ROM), including for example one or more levelsof cached memory) may also form part of CPU 12. However, there are manydifferent ways in which memory may be coupled to system 10. Memory 11may be used for a variety of purposes such as, for example, cachingand/or storing data, programming instructions, and the like. It shouldbe further appreciated that CPU 12 may be one of a variety ofsystem-on-a-chip (SOC) type hardware that may include additionalhardware such as memory or graphics processing chips, such as a QUALCOMMSNAPDRAGON™ or SAMSUNG EXYNOS™ CPU as are becoming increasingly commonin the art, such as for use in mobile devices or integrated devices.

As used herein, the term “processor” is not limited merely to thoseintegrated circuits referred to in the art as a processor, a mobileprocessor, or a microprocessor, but broadly refers to a microcontroller,a microcomputer, a programmable logic controller, anapplication-specific integrated circuit, and any other programmablecircuit.

In one embodiment, interfaces 15 are provided as network interface cards(NICs). Generally, NICs control the sending and receiving of datapackets over a computer network; other types of interfaces 15 may forexample support other peripherals used with computing device 10. Amongthe interfaces that may be provided are Ethernet interfaces, frame relayinterfaces, cable interfaces, DSL interfaces, token ring interfaces,graphics interfaces, and the like. In addition, various types ofinterfaces may be provided such as, for example, universal serial bus(USB), Serial, Ethernet, FIREWIRE™, THUNDERBOLT™, PCI, parallel, radiofrequency (RF), BLUETOOTH™, near-field communications (e.g., usingnear-field magnetics), 802.11 (Wi-Fi), frame relay, TCP/IP, ISDN, fastEthernet interfaces, Gigabit Ethernet interfaces, Serial ATA (SATA) orexternal SATA (ESATA) interfaces, high-definition multimedia interface(HDMI), digital visual interface (DVI), analog or digital audiointerfaces, asynchronous transfer mode (ATM) interfaces, high-speedserial interface (HSSI) interfaces, Point of Sale (POS) interfaces,fiber data distributed interfaces (FDDIs), and the like. Generally, suchinterfaces 15 may include physical ports appropriate for communicationwith appropriate media. In some cases, they may also include anindependent processor (such as a dedicated audio or video processor, asis common in the art for high-fidelity A/V hardware interfaces) and, insome instances, volatile and/or non-volatile memory (e.g., RAM).

Although the system shown in FIG. 26 illustrates one specificarchitecture for a computing device 10 for implementing one or more ofthe inventions described herein, it is by no means the only devicearchitecture on which at least a portion of the features and techniquesdescribed herein may be implemented. For example, architectures havingone or any number of processors 13 may be used, and such processors 13may be present in a single device or distributed among any number ofdevices. In one embodiment, a single processor 13 handles communicationsas well as routing computations, while in other embodiments a separatededicated communications processor may be provided. In variousembodiments, different types of features or functionalities may beimplemented in a system according to the invention that includes aclient device (such as a tablet device or smartphone running clientsoftware) and server systems (such as a server system described in moredetail below).

Regardless of network device configuration, the system of the presentinvention may employ one or more memories or memory modules (such as,for example, remote memory block 16 and local memory 11) configured tostore data, program instructions for the general-purpose networkoperations, or other information relating to the functionality of theembodiments described herein (or any combinations of the above). Programinstructions may control execution of or comprise an operating systemand/or one or more applications, for example. Memory 16 or memories 11,16 may also be configured to store data structures, configuration data,encryption data, historical system operations information, or any otherspecific or generic non-program information described herein.

Because such information and program instructions may be employed toimplement one or more systems or methods described herein, at least somenetwork device embodiments may include non-transitory machine-readablestorage media, which, for example, may be configured or designed tostore program instructions, state information, and the like forperforming various operations described herein. Examples of suchnon-transitory machine- readable storage media include, but are notlimited to, magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD- ROM disks; magneto-opticalmedia such as optical disks, and hardware devices that are speciallyconfigured to store and perform program instructions, such as read-onlymemory devices (ROM), flash memory (as is common in mobile devices andintegrated systems), solid state drives (SSD) and “hybrid SSD” storagedrives that may combine physical components of solid state and hard diskdrives in a single hardware device (as are becoming increasingly commonin the art with regard to personal computers), memristor memory, randomaccess memory (RAM), and the like. It should be appreciated that suchstorage means may be integral and non-removable (such as RAM hardwaremodules that may be soldered onto a motherboard or otherwise integratedinto an electronic device), or they may be removable such as swappableflash memory modules (such as “thumb drives” or other removable mediadesigned for rapidly exchanging physical storage devices),“hot-swappable” hard disk drives or solid state drives, removableoptical storage discs, or other such removable media, and that suchintegral and removable storage media may be utilized interchangeably.Examples of program instructions include both object code, such as maybe produced by a compiler, machine code, such as may be produced by anassembler or a linker, byte code, such as may be generated by forexample a JAVA™ compiler and may be executed using a Java virtualmachine or equivalent, or files containing higher level code that may beexecuted by the computer using an interpreter (for example, scriptswritten in Python, Perl, Ruby, Groovy, or any other scripting language).

In some embodiments, systems according to the present invention may beimplemented on a standalone computing system. Referring now to FIG. 27 ,there is shown a block diagram depicting a typical exemplaryarchitecture of one or more embodiments or components thereof on astandalone computing system. Computing device 20 includes processors 21that may run software that carry out one or more functions orapplications of embodiments of the invention, such as for example aclient application 24. Processors 21 may carry out computinginstructions under control of an operating system 22 such as, forexample, a version of MICROSOFT WINDOWS™ operating system, APPLE OSX™ oriOS™ operating systems, some variety of the Linux operating system,ANDROID™ operating system, or the like. In many cases, one or moreshared services 23 may be operable in system 20, and may be useful forproviding common services to client applications 24. Services 23 may forexample be WINDOWS™ services, user-space common services in a Linuxenvironment, or any other type of common service architecture used withoperating system 21. Input devices 28 may be of any type suitable forreceiving user input, including for example a keyboard, touchscreen,microphone (for example, for voice input), mouse, touchpad, trackball,or any combination thereof. Output devices 27 may be of any typesuitable for providing output to one or more users, whether remote orlocal to system 20, and may include for example one or more screens forvisual output, speakers, printers, or any combination thereof. Memory 25may be random-access memory having any structure and architecture knownin the art, for use by processors 21, for example to run software.Storage devices 26 may be any magnetic, optical, mechanical, memristor,or electrical storage device for storage of data in digital form (suchas those described above, referring to FIG. 26 ). Examples of storagedevices 26 include flash memory, magnetic hard drive, CD-ROM, and/or thelike.

In some embodiments, systems of the present invention may be implementedon a distributed computing network, such as one having any number ofclients and/or servers. Referring now to FIG. 28 , there is shown ablock diagram depicting an exemplary architecture 30 for implementing atleast a portion of a system according to an embodiment of the inventionon a distributed computing network. According to the embodiment, anynumber of clients 33 may be provided. Each client 33 may run softwarefor implementing client-side portions of the present invention; clientsmay comprise a system 20 such as that illustrated in FIG. 27 . Inaddition, any number of servers 32 may be provided for handling requestsreceived from one or more clients 33. Clients 33 and servers 32 maycommunicate with one another via one or more electronic networks 31,which may be in various embodiments any of the Internet, a wide areanetwork, a mobile telephony network (such as CDMA or GSM cellularnetworks), a wireless network (such as WiFi, WiMAX, LTE, and so forth),or a local area network (or indeed any network topology known in theart; the invention does not prefer any one network topology over anyother). Networks 31 may be implemented using any known networkprotocols, including for example wired and/or wireless protocols.

In addition, in some embodiments, servers 32 may call external services37 when needed to obtain additional information, or to refer toadditional data concerning a particular call. Communications withexternal services 37 may take place, for example, via one or morenetworks 31. In various embodiments, external services 37 may compriseweb-enabled services or functionality related to or installed on thehardware device itself. For example, in an embodiment where clientapplications 24 are implemented on a smartphone or other electronicdevice, client applications 24 may obtain information stored in a serversystem 32 in the cloud or on an external service 37 deployed on one ormore of a particular enterprise’s or user’s premises.

In some embodiments of the invention, clients 33 or servers 32 (or both)may make use of one or more specialized services or appliances that maybe deployed locally or remotely across one or more networks 31. Forexample, one or more databases 34 may be used or referred to by one ormore embodiments of the invention. It should be understood by one havingordinary skill in the art that databases 34 may be arranged in a widevariety of architectures and using a wide variety of data access andmanipulation means. For example, in various embodiments one or moredatabases 34 may comprise a relational database system using astructured query language (SQL), while others may comprise analternative data storage technology such as those referred to in the artas “NoSQL” (for example, HADOOP CASSANDRA™, GOOGLE BIGTABLE™, and soforth). In some embodiments, variant database architectures such ascolumn-oriented databases, in-memory databases, clustered databases,distributed databases, or even flat file data repositories may be usedaccording to the invention. It will be appreciated by one havingordinary skill in the art that any combination of known or futuredatabase technologies may be used as appropriate, unless a specificdatabase technology or a specific arrangement of components is specifiedfor a particular embodiment herein. Moreover, it should be appreciatedthat the term “database” as used herein may refer to a physical databasemachine, a cluster of machines acting as a single database system, or alogical database within an overall database management system. Unless aspecific meaning is specified for a given use of the term “database”, itshould be construed to mean any of these senses of the word, all ofwhich are understood as a plain meaning of the term “database” by thosehaving ordinary skill in the art.

Similarly, most embodiments of the invention may make use of one or moresecurity systems 36 and configuration systems 35. Security andconfiguration management are common information technology (IT) and webfunctions, and some amount of each are generally associated with any ITor web systems. It should be understood by one having ordinary skill inthe art that any configuration or security subsystems known in the artnow or in the future may be used in conjunction with embodiments of theinvention without limitation, unless a specific security 36 orconfiguration system 35 or approach is specifically required by thedescription of any specific embodiment.

FIG. 29 shows an exemplary overview of a computer system 40 as may beused in any of the various locations throughout the system. It isexemplary of any computer that may execute code to process data. Variousmodifications and changes may be made to computer system 40 withoutdeparting from the broader scope of the system and method disclosedherein. Central processor unit (CPU) 41 is connected to bus 42, to whichbus is also connected memory 43, nonvolatile memory 44, display 47,input/output (I/O) unit 48, and network interface card (NIC) 53. I/Ounit 48 may, typically, be connected to keyboard 49, pointing device 50,hard disk 52, and real-time clock 51. NIC 53 connects to network 54,which may be the Internet or a local network, which local network may ormay not have connections to the Internet. Also shown as part of system40 is power supply unit 45 connected, in this example, to a mainalternating current (AC) supply 46. Not shown are batteries that couldbe present, and many other devices and modifications that are well knownbut are not applicable to the specific novel functions of the currentsystem and method disclosed herein. It should be appreciated that someor all components illustrated may be combined, such as in variousintegrated applications, for example Qualcomm or Samsungsystem-on-a-chip (SOC) devices, or whenever it may be appropriate tocombine multiple capabilities or functions into a single hardware device(for instance, in mobile devices such as smartphones, video gameconsoles, in-vehicle computer systems such as navigation or multimediasystems in automobiles, or other integrated hardware devices).

In various embodiments, functionality for implementing systems ormethods of the present invention may be distributed among any number ofclient and/or server components. For example, various software modulesmay be implemented for performing various functions in connection withthe present invention, and such modules may be variously implemented torun on server and/or client components.

The skilled person will be aware of a range of possible modifications ofthe various embodiments described above. Accordingly, the presentinvention is defined by the claims and their equivalents.

What is claimed is:
 1. A system for enhanced virtual queuing with accesscontrol, comprising: a computing device comprising a memory, aprocessor, and a non-volatile data storage device; a queue managercomprising a first plurality of programming instructions stored in thememory which, when operating on the processor, causes the processor to:receive a user request to join a virtual queue for a controlled system;assign the user a queue position; continuously monitor the queue stateby analyzing data received from a plurality of sensors; and notify theuser when the user has reached the front of the queue; and a securitymodule comprising a second plurality of programming instructions storedin the memory which, when operating on the processor, causes theprocessor to: generate an access key for the user; send the access keyto a user device associated with the user; and provide access to thecontrolled system when the user has reached the front of the queue bydetecting the access key using one of the plurality of sensors.
 2. Thesystem of claim 1, wherein the queue manager is further configured todetect a queue event based on the analysis of the received data from theplurality of sensors and send detected event data to a queue loadbalancer.
 3. The system of claim 2, further comprising the queue loadbalancer comprising a third plurality of programming instructions storedin the memory which, when operating on the processor, causes theprocessor to: receive the detected event data from the queue manager;calculate a current queue throughput based on the received event data;compare the current queue throughput to a predicted throughput todetermine an estimated wait time; and reassign the user among aplurality of virtual queues to minimize the wait time.
 4. The system ofclaim 1, wherein the controlled system is a physical system.
 5. Thesystem of claim 1, wherein the controlled system is a virtual system. 6.The system of claim 2, wherein the queue event is selected from thegroup consisting of a request to join the virtual queue, a request toleave the virtual queue, and additional queues opening or closing.
 7. Amethod for enhanced virtual queuing with access control, comprising thesteps of: receiving a user request to join a virtual queue for acontrolled system; assigning the user a queue position; continuouslymonitoring the queue state by analyzing data received from a pluralityof sensors; notifying the user when the user has reached the front ofthe queue; generating an access key for the user; sending the access keyto a user device associated with the user; and providing access to thecontrolled system when the user has reached the front of the queue bydetecting the access key using one of the plurality of sensors.
 8. Themethod of claim 7, further comprising the steps of detecting a queueevent based on the analysis of the received data from the plurality ofsensors and sending detected event data to a queue load balancer.
 9. Themethod of claim 8, further comprising the steps of: receiving thedetected event data from the queue manager; calculating a current queuethroughput based on the received event data; comparing the current queuethroughput to a predicted throughput to determine an estimated waittime; and reassigning the user among a plurality of virtual queues tominimize the wait time.
 10. The method of claim 7, wherein thecontrolled system is a physical system.
 11. The method of claim 7,wherein the controlled system is a virtual system.
 12. The method ofclaim 8, wherein the queue event is selected from the group consistingof a request to join the virtual queue, a request to leave the virtualqueue, and additional queues opening or closing.